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

[osstest service owner]

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

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-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-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-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 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-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  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-qemuu-rhel6hvm-amd  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-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit1   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-xsm1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   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-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 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  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-pvshim1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-xsm  1 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-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 

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

[osstest service owner]

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

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-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  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-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-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-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  6d786f95a366600e7bbae68c1b324a8131f5e2c5
baseline version:
 libvirt  a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z7 days
Failing since146211  2020-01-18 04:18:52 Z6 days7 attempts
Testing same since   146455  2020-01-24 04:19:03 Z0 days1 attempts


People who touched revisions under test:
  Boris Fiuczynski 
  Christian Ehrhardt 
  Daniel P. Berrangé 
  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
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not 

Re: [Xen-devel] [PATCH] xen/sched: avoid cpumasks on stack in sched/core.c

[Jürgen Groß]

On 24.01.20 01:01, Dario Faggioli wrote:

On Thu, 2020-01-23 at 10:03 +0100, Juergen Gross wrote:

There are still several instances of cpumask_t on the stack in
scheduling code. Avoid them as far as possible.

Signed-off-by: Juergen Gross 


Reviewed-by: Dario Faggioli 

Just curious...


--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2586,11 +2582,11 @@ static void schedule(void)
  
  if ( gran > 1 )

  {
-cpumask_t mask;
+cpumask_t *mask = cpumask_scratch_cpu(cpu);
  
  prev->rendezvous_in_cnt = gran;

-cpumask_andnot(, sr->cpus, cpumask_of(cpu));
-cpumask_raise_softirq(, SCHED_SLAVE_SOFTIRQ);
+cpumask_andnot(mask, sr->cpus, cpumask_of(cpu));
+cpumask_raise_softirq(mask, SCHED_SLAVE_SOFTIRQ);


... why are we keeping the temporary variable (mask) ?


per_cpu accesses are more expensive than those to local variables.
mask is used twice.


Juergen

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

[Xen-devel] [xen-unstable-smoke test] 146457: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
baseline version:
 xen  021cc01ecac111be3301ad33ff5cda4543ca8b92

Last test of basis   146401  2020-01-22 23:00:35 Z1 days
Testing same since   146420  2020-01-23 15:00:29 Z0 days7 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  George Dunlap 
  Jan Beulich 
  Tamas K Lengyel 

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


Not pushing.


commit 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:33 2020 +

x86/mm: Make use of the default access param from xc_altp2m_create_view

At this moment the default_access param from xc_altp2m_create_view is
not used.

This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.

Signed-off-by: Alexandru Isaila 
Acked-by: Jan Beulich 
Acked-by: Tamas K Lengyel 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit b701adbee37befa58c7bdec80b65f93e033252e6
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:31 2020 +

x86/mm: Pull vendor-independent altp2m code out of p2m-ept.c and into p2m.c

No functional changes.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit ea22bcd030da771be18821bf4a898ed7a314eb83
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:30 2020 +

x86/altp2m: Add hypercall to set a range of sve bits

By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not break in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for continuation is made in order to have
preemption on large ranges.
The gfn of the first error is stored in
xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
If no error occurred the values will be 0.

Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit 5160dbd512523d865f7271af23636aa3f3536186
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:26 2020 +

x86/mm: Add array_index_nospec to guest provided index values

This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
(qemu changes not included)

___
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]

Hi Vincenzo,

On Thu, Jan 23, 2020 at 10:48:07AM +, Vincenzo Frascino wrote:
> Hi Boqun Feng,
> 
> sorry for the late reply.
> 

That's OK, thanks for your review ;-)

> On 16/12/2019 00:19, Boqun Feng wrote:
> > Hi,
> > 
> > This is the RFC patchset for vDSO support in ARM64 Hyper-V guest. To
> > test it, Michael's ARM64 support patchset:
> > 
> > 
> > https://lore.kernel.org/linux-arm-kernel/1570129355-16005-1-git-send-email-mikel...@microsoft.com/
> > 
> > is needed.
> > 
> > Similar as x86, Hyper-V on ARM64 use a TSC page for guests to read
> > the virtualized hardware timer, this TSC page is read-only for the
> > guests, so could be used for vDSO data page. And the vDSO (userspace)
> > code could use the same code for timer reading as kernel, since
> > they read the same TSC page.
> > 
> 
> 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.

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.

?

Regards,
Boqun

> > This patchset therefore extends ARM64's __vsdo_init() to allow multiple
> > data pages and introduces the vclock_mode concept similar to x86 to
> > allow different platforms (bare-metal, Hyper-V, etc.) to switch to
> > different __arch_get_hw_counter() implementations. The rest of this
> > patchset does the necessary setup for Hyper-V guests: mapping tsc page,
> > enabling userspace to read cntvct, etc. to enable vDSO.
> > 
> > This patchset consists of 6 patches:
> > 
> > patch #1 allows hv_get_raw_timer() definition to be overridden for
> > userspace and kernel to share the same hv_read_tsc_page() definition.
> > 
> > patch #2 extends ARM64 to support multiple vDSO data pages.
> > 
> > patch #3 introduces vclock_mode similiar to x86 to allow different
> > __arch_get_hw_counter() implementations for different clocksources.
> > 
> > patch #4 maps Hyper-V TSC page into vDSO data page.
> > 
> > patch #5 allows userspace to read cntvct, so that userspace can
> > efficiently read the clocksource.
> > 
> > patch #6 enables the vDSO for ARM64 Hyper-V guest.
> > 
> > The whole patchset is based on v5.5-rc1 plus Michael's ARM64 support
> > patchset, and I've done a few tests with:
> > 
> > https://github.com/nlynch-mentor/vdsotest
> > 
> > Comments and suggestions are welcome!
> > 
> > Regards,
> > Boqun
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 
> -- 
> Regards,
> Vincenzo



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
146121
 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

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-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-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 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-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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
 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 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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 linux0fce94b45b53c9fb1657a94f3419a67b61e0344c
baseline version:
 linux122179cb7d648a6f36b20dd6bf34f953cb384c30

[Xen-devel] [xen-unstable-smoke test] 146454: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
baseline version:
 xen  021cc01ecac111be3301ad33ff5cda4543ca8b92

Last test of basis   146401  2020-01-22 23:00:35 Z1 days
Testing same since   146420  2020-01-23 15:00:29 Z0 days6 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  George Dunlap 
  Jan Beulich 
  Tamas K Lengyel 

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


Not pushing.


commit 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:33 2020 +

x86/mm: Make use of the default access param from xc_altp2m_create_view

At this moment the default_access param from xc_altp2m_create_view is
not used.

This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.

Signed-off-by: Alexandru Isaila 
Acked-by: Jan Beulich 
Acked-by: Tamas K Lengyel 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit b701adbee37befa58c7bdec80b65f93e033252e6
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:31 2020 +

x86/mm: Pull vendor-independent altp2m code out of p2m-ept.c and into p2m.c

No functional changes.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit ea22bcd030da771be18821bf4a898ed7a314eb83
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:30 2020 +

x86/altp2m: Add hypercall to set a range of sve bits

By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not break in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for continuation is made in order to have
preemption on large ranges.
The gfn of the first error is stored in
xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
If no error occurred the values will be 0.

Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit 5160dbd512523d865f7271af23636aa3f3536186
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:26 2020 +

x86/mm: Add array_index_nospec to guest provided index values

This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
(qemu changes not included)

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

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

[osstest service owner]

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

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-i386-freebsd10-i386  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-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  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-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  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-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-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  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-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 

[Xen-devel] [xen-unstable-smoke test] 146447: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
baseline version:
 xen  021cc01ecac111be3301ad33ff5cda4543ca8b92

Last test of basis   146401  2020-01-22 23:00:35 Z1 days
Testing same since   146420  2020-01-23 15:00:29 Z0 days5 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  George Dunlap 
  Jan Beulich 
  Tamas K Lengyel 

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


Not pushing.


commit 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:33 2020 +

x86/mm: Make use of the default access param from xc_altp2m_create_view

At this moment the default_access param from xc_altp2m_create_view is
not used.

This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.

Signed-off-by: Alexandru Isaila 
Acked-by: Jan Beulich 
Acked-by: Tamas K Lengyel 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit b701adbee37befa58c7bdec80b65f93e033252e6
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:31 2020 +

x86/mm: Pull vendor-independent altp2m code out of p2m-ept.c and into p2m.c

No functional changes.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit ea22bcd030da771be18821bf4a898ed7a314eb83
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:30 2020 +

x86/altp2m: Add hypercall to set a range of sve bits

By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not break in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for continuation is made in order to have
preemption on large ranges.
The gfn of the first error is stored in
xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
If no error occurred the values will be 0.

Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit 5160dbd512523d865f7271af23636aa3f3536186
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:26 2020 +

x86/mm: Add array_index_nospec to guest provided index values

This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
(qemu changes not included)

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

[Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm

[osstest service owner]

branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build

Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  ea22bcd030da771be18821bf4a898ed7a314eb83
  Bug not present: 5160dbd512523d865f7271af23636aa3f3536186
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/146449/


  commit ea22bcd030da771be18821bf4a898ed7a314eb83
  Author: Alexandru Stefan ISAILA 
  Date:   Fri Jan 17 13:31:30 2020 +
  
  x86/altp2m: Add hypercall to set a range of sve bits
  
  By default the sve bits are not set.
  This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
  to set a range of sve bits.
  The core function, p2m_set_suppress_ve_multi(), does not break in case
  of a error and it is doing a best effort for setting the bits in the
  given range. A check for continuation is made in order to have
  preemption on large ranges.
  The gfn of the first error is stored in
  xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
  stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
  If no error occurred the values will be 0.
  
  Signed-off-by: Alexandru Isaila 
  Reviewed-by: Jan Beulich 
  Reviewed-by: Petre Pircalabu 
  Acked-by: George Dunlap 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build
 --summary-out=tmp/146449.bisection-summary --basis-template=146401 
--blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build
Searching for failure / basis pass:
 146438 fail [host=rochester0] / 146401 [host=rochester1] 146396 [host=laxton0] 
146390 [host=laxton1] 146367 [host=laxton1] 146362 [host=laxton1] 146353 
[host=laxton1] 146330 [host=rochester1] 146321 [host=rochester1] 146218 ok.
Failure / basis pass flights: 146438 / 146218
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 933ebad2470a169504799a1d95b8e410bd9847ef 
2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Basis pass 933ebad2470a169504799a1d95b8e410bd9847ef 
1eeedaf5a0d9ed6324f3bd5b700bb22eb4355341
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef
 
git://xenbits.xen.org/xen.git#1eeedaf5a0d9ed6324f3bd5b700bb22eb4355341-2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Loaded 5001 nodes in revision graph
Searching for test results:
 146218 pass 933ebad2470a169504799a1d95b8e410bd9847ef 
1eeedaf5a0d9ed6324f3bd5b700bb22eb4355341
 146321 [host=rochester1]
 146330 [host=rochester1]
 146367 [host=laxton1]
 146353 [host=laxton1]
 146362 [host=laxton1]
 146390 [host=laxton1]
 146396 [host=laxton0]
 146401 [host=rochester1]
 146429 pass 933ebad2470a169504799a1d95b8e410bd9847ef 
c081788f80f828a021bb192411da05133bd13957
 146420 fail 933ebad2470a169504799a1d95b8e410bd9847ef 
2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
 146425 pass 933ebad2470a169504799a1d95b8e410bd9847ef 
1eeedaf5a0d9ed6324f3bd5b700bb22eb4355341
 146426 fail 933ebad2470a169504799a1d95b8e410bd9847ef 
2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
 146428 pass 933ebad2470a169504799a1d95b8e410bd9847ef 
6cb4b01c033b7abc3e7175501330dfb01fb09da5
 146430 pass 933ebad2470a169504799a1d95b8e410bd9847ef 
c5bcf30b2cfaec6bb1924e96d77134121d023692
 146431 pass 933ebad2470a169504799a1d95b8e410bd9847ef 
5160dbd512523d865f7271af23636aa3f3536186
 146433 fail 933ebad2470a169504799a1d95b8e410bd9847ef 
ea22bcd030da771be18821bf4a898ed7a314eb83
 146427 fail 933ebad2470a169504799a1d95b8e410bd9847ef 
2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
 146434 pass 933ebad2470a169504799a1d95b8e410bd9847ef 
5160dbd512523d865f7271af23636aa3f3536186
 146436 fail 933ebad2470a169504799a1d95b8e410bd9847ef 
ea22bcd030da771be18821bf4a898ed7a314eb83
 146435 [host=rochester1]
 146437 pass 933ebad2470a169504799a1d95b8e410bd9847ef 
5160dbd512523d865f7271af23636aa3f3536186
 146440 [host=rochester1]
 146441 [host=rochester1]
 146442 [host=rochester1]
 146443 [host=rochester1]
 146444 [host=rochester1]
 146438 fail 933ebad2470a169504799a1d95b8e410bd9847ef 
2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
 146446 [host=rochester1]
 146449 fail 933ebad2470a169504799a1d95b8e410bd9847ef 
ea22bcd030da771be18821bf4a898ed7a314eb83
Searching for interesting versions
 Result found: flight 146218 (pass), for basis pass
 Result found: flight 146420 (fail), for basis failure
 Repro found: flight 146425 (pass), for basis pass
 Repro found: flight 146426 (fail), for basis failure
 0 revisions at 

Re: [Xen-devel] [PATCH] xen/sched: avoid cpumasks on stack in sched/core.c

[Dario Faggioli]

On Thu, 2020-01-23 at 10:03 +0100, Juergen Gross wrote:
> There are still several instances of cpumask_t on the stack in
> scheduling code. Avoid them as far as possible.
> 
> Signed-off-by: Juergen Gross 
>
Reviewed-by: Dario Faggioli 

Just curious...

> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -2586,11 +2582,11 @@ static void schedule(void)
>  
>  if ( gran > 1 )
>  {
> -cpumask_t mask;
> +cpumask_t *mask = cpumask_scratch_cpu(cpu);
>  
>  prev->rendezvous_in_cnt = gran;
> -cpumask_andnot(, sr->cpus, cpumask_of(cpu));
> -cpumask_raise_softirq(, SCHED_SLAVE_SOFTIRQ);
> +cpumask_andnot(mask, sr->cpus, cpumask_of(cpu));
> +cpumask_raise_softirq(mask, SCHED_SLAVE_SOFTIRQ);
>
... why are we keeping the temporary variable (mask) ?

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



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

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

[osstest service owner]

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

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-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  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-ovmf-amd64  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-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  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-arm64-arm64-xl   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-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  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-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 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-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   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-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   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-amd64-amd64-xl-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-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-arm64-arm64-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-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-pvgrub  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-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 

[Xen-devel] [xen-unstable-smoke test] 146438: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
baseline version:
 xen  021cc01ecac111be3301ad33ff5cda4543ca8b92

Last test of basis   146401  2020-01-22 23:00:35 Z1 days
Testing same since   146420  2020-01-23 15:00:29 Z0 days4 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  George Dunlap 
  Jan Beulich 
  Tamas K Lengyel 

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


Not pushing.


commit 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:33 2020 +

x86/mm: Make use of the default access param from xc_altp2m_create_view

At this moment the default_access param from xc_altp2m_create_view is
not used.

This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.

Signed-off-by: Alexandru Isaila 
Acked-by: Jan Beulich 
Acked-by: Tamas K Lengyel 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit b701adbee37befa58c7bdec80b65f93e033252e6
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:31 2020 +

x86/mm: Pull vendor-independent altp2m code out of p2m-ept.c and into p2m.c

No functional changes.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit ea22bcd030da771be18821bf4a898ed7a314eb83
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:30 2020 +

x86/altp2m: Add hypercall to set a range of sve bits

By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not break in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for continuation is made in order to have
preemption on large ranges.
The gfn of the first error is stored in
xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
If no error occurred the values will be 0.

Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit 5160dbd512523d865f7271af23636aa3f3536186
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:26 2020 +

x86/mm: Add array_index_nospec to guest provided index values

This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
(qemu changes not included)

___
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

[Lars Kurth]

> On 23 Jan 2020, at 05:31, Bobby Eshleman  wrote:
> 
> On Wed, Jan 22, 2020 at 04:27:39PM +, Lars Kurth wrote:
>> 
>> You should also leverage the developer summit: see 
>> https://events.linuxfoundation.org/xen-summit/program/cfp/ 
>> 
>> CfP closes March 6th. Design sessions can be submitted afterwards
>> 
>> Community calls may also be a good option to deal with specific issues / 
>> questions, e.g. around compile support in the CI, etc.
>> 
>> Lars
>> 
> 
> That's a really good idea.  I'll submit as I do think I can get there if 
> accepted.  Thanks for the tip on
> community calls, I did not realize Xen did those!
> 
> -Bobby

If you add your name/email address to 
https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/ 
 I will CC you 
on the next invite
They are usually the 1st Thursday of each month 
Past minutes can be found at 
https://cryptpad.fr/drive/#/2/drive/edit/uZ1UjYxICjse+XlJrXrIwZXN/
Lars___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

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 9a1f14ad721bbcd833ec5108944c44a502392f03
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z   15 days
Failing since145774  2020-01-08 02:50:20 Z   15 days   58 attempts
Testing same since   146346  2020-01-21 04:31:27 Z2 days   10 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 1164 lines long.)

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 146058
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 146058

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
146408
 test-armhf-armhf-xl-rtds 15 guest-stop fail pass in 146408

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10  fail blocked in 146058
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 146408 like 
146050
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 146058
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 146058
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 146058
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 146058
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 
146058
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 146058
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 146058
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 146058
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 146058
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 146058
 test-amd64-i386-xl-pvshim12 guest-start  fail   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 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-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-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  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-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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-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-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-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop   

Re: [Xen-devel] HVM Driver Domain

[Marek Marczykowski-Górecki]

On Thu, Jan 23, 2020 at 10:36:34PM +, tosher 1 wrote:
> 
> 
> I wasn't able to make the HVM driver domain work even with the latest Xen 
> version which is 4.14. I see the 'xendriverdomain' executable in the 
> /etc/init.d/ directory, but it doesn't seem to be running in the background. 
> 
> On the other hand, I see the official "Qubes OS Architecture" document 
> (https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf)
>  defines the driver domain as the following.
> 
> "A driver domain is an unprivileged PV-domain that has been securely granted 
> access to certain PCI device (e.g. the network card or disk controller) using 
> Intel VT-d." - Page 12
> 
> Moreover, section 6.1 reads "The network domain is granted direct access to 
> the networking hardware, e.g. the WiFi or ethernet card. Besides, it is a 
> regular unprivileged PV domain."
> 
> Maybe you guys later moved to the HVM driver domain from PV. Would you please 
> share the Xen config you use for the network driver domain?

Yes, that PDF is quite outdated, we use HVM now.

As for the configs, as said before, we use libvirt, with some extra
patches, so the config won't be directly useful for you. I'm attaching
both libvirt XML for the driver domain, and also converted to XL (using
virsh domxml-to-native), may be inaccurate.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
name = "sys-net"
uuid = "f8716f60-6be1-43b5-9bcb-b2c8c0910e5b"
maxmem = 400
memory = 400
vcpus = 2
pae = 1
acpi = 1
apic = 1
viridian = 1
rtc_timeoffset = 0
localtime = 1
on_poweroff = "destroy"
on_reboot = "destroy"
on_crash = "destroy"
sdl = 0
vnc = 1
vncunused = 0
vncdisplay = -5900
pci = [ ":00:1f.6", ":04:00.0" ]
parallel = "none"
serial = "none"
builder = "hvm"
cmdline = "root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH 
rd.plymouth.enable=0 plymouth.enable=0 xen_scrub_pages=0 nopat iommu=soft 
swiotlb=8192"
boot = "dc"
nestedhvm = 0
disk = [ 
"format=raw,vdev=xvda,access=rw,backendtype=phy,target=/dev/qubes_dom0/vm-sys-net-root-snap",
 
"format=raw,vdev=xvdb,access=rw,backendtype=phy,target=/dev/qubes_dom0/vm-sys-net-private-snap",
 
"format=raw,vdev=xvdc,access=rw,backendtype=phy,target=/dev/qubes_dom0/vm-sys-net-volatile",
 
"format=raw,vdev=xvdd,access=ro,backendtype=phy,target=/var/lib/qubes/vm-kernels/4.19.86-1/modules.img"
 ]
usb = 1
usbdevice = "tablet"


  sys-net
  f8716f60-6be1-43b5-9bcb-b2c8c0910e5b
  409600
  409600
  2
  
hvm
hvmloader
root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH rd.plymouth.enable=0 plymouth.enable=0 xen_scrub_pages=0 nopat iommu=soft swiotlb=8192


  
  





  

  
  



  
  
  destroy
  destroy
  destroy
  


  
  
  
  


  
  
  
  


  
  
  
  


  
  
  
  
  


  
  






  


  
  

  


  
  

  

  




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

Re: [Xen-devel] HVM Driver Domain

[tosher 1]

I wasn't able to make the HVM driver domain work even with the latest Xen 
version which is 4.14. I see the 'xendriverdomain' executable in the 
/etc/init.d/ directory, but it doesn't seem to be running in the background. 

On the other hand, I see the official "Qubes OS Architecture" document 
(https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf) 
defines the driver domain as the following.

"A driver domain is an unprivileged PV-domain that has been securely granted 
access to certain PCI device (e.g. the network card or disk controller) using 
Intel VT-d." - Page 12

Moreover, section 6.1 reads "The network domain is granted direct access to the 
networking hardware, e.g. the WiFi or ethernet card. Besides, it is a regular 
unprivileged PV domain."

Maybe you guys later moved to the HVM driver domain from PV. Would you please 
share the Xen config you use for the network driver domain?

Thanks,
Mehrab


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

[Xen-devel] [xen-unstable-smoke test] 146435: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
baseline version:
 xen  021cc01ecac111be3301ad33ff5cda4543ca8b92

Last test of basis   146401  2020-01-22 23:00:35 Z0 days
Testing same since   146420  2020-01-23 15:00:29 Z0 days3 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  George Dunlap 
  Jan Beulich 
  Tamas K Lengyel 

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


Not pushing.


commit 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:33 2020 +

x86/mm: Make use of the default access param from xc_altp2m_create_view

At this moment the default_access param from xc_altp2m_create_view is
not used.

This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.

Signed-off-by: Alexandru Isaila 
Acked-by: Jan Beulich 
Acked-by: Tamas K Lengyel 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit b701adbee37befa58c7bdec80b65f93e033252e6
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:31 2020 +

x86/mm: Pull vendor-independent altp2m code out of p2m-ept.c and into p2m.c

No functional changes.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit ea22bcd030da771be18821bf4a898ed7a314eb83
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:30 2020 +

x86/altp2m: Add hypercall to set a range of sve bits

By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not break in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for continuation is made in order to have
preemption on large ranges.
The gfn of the first error is stored in
xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
If no error occurred the values will be 0.

Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit 5160dbd512523d865f7271af23636aa3f3536186
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:26 2020 +

x86/mm: Add array_index_nospec to guest provided index values

This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
(qemu changes not included)

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

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

[osstest service owner]

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

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-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  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-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  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   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  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-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-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-i386-xl-raw1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  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-pvshim1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-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-i386-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-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  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-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 

[Xen-devel] [examine test] 146421: tolerable trouble: pass/starved

[osstest service owner]

flight 146421 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146421/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 examine-elbling1  2 hosts-allocate   starved  n/a
 examine-pinot02 hosts-allocate   starved  n/a
 examine-elbling0  2 hosts-allocate   starved  n/a
 examine-debina0   2 hosts-allocate   starved  n/a

baseline version:
 flight   145152

jobs:
 examine-albana0  pass
 examine-albana1  pass
 examine-arndale-bluewaterpass
 examine-cubietruck-braquepass
 examine-chardonnay0  pass
 examine-chardonnay1  pass
 examine-debina0  starved 
 examine-debina1  pass
 examine-elbling0 starved 
 examine-elbling1 starved 
 examine-fiano0   pass
 examine-fiano1   pass
 examine-cubietruck-gleizes   pass
 examine-godello0 pass
 examine-godello1 pass
 examine-huxelrebe0   pass
 examine-huxelrebe1   pass
 examine-italia0  pass
 examine-arndale-lakeside pass
 examine-laxton0  pass
 examine-laxton1  pass
 examine-arndale-metrocentre  pass
 examine-cubietruck-metzinger pass
 examine-cubietruck-picasso   pass
 examine-pinot0   starved 
 examine-pinot1   pass
 examine-rimava1  pass
 examine-rochester0   pass
 examine-rochester1   pass
 examine-arndale-westfieldpass



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


Push not applicable.


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

[Xen-devel] [xen-unstable-smoke test] 146427: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
baseline version:
 xen  021cc01ecac111be3301ad33ff5cda4543ca8b92

Last test of basis   146401  2020-01-22 23:00:35 Z0 days
Testing same since   146420  2020-01-23 15:00:29 Z0 days2 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  George Dunlap 
  Jan Beulich 
  Tamas K Lengyel 

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


Not pushing.


commit 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:33 2020 +

x86/mm: Make use of the default access param from xc_altp2m_create_view

At this moment the default_access param from xc_altp2m_create_view is
not used.

This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.

Signed-off-by: Alexandru Isaila 
Acked-by: Jan Beulich 
Acked-by: Tamas K Lengyel 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit b701adbee37befa58c7bdec80b65f93e033252e6
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:31 2020 +

x86/mm: Pull vendor-independent altp2m code out of p2m-ept.c and into p2m.c

No functional changes.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit ea22bcd030da771be18821bf4a898ed7a314eb83
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:30 2020 +

x86/altp2m: Add hypercall to set a range of sve bits

By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not break in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for continuation is made in order to have
preemption on large ranges.
The gfn of the first error is stored in
xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
If no error occurred the values will be 0.

Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit 5160dbd512523d865f7271af23636aa3f3536186
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:26 2020 +

x86/mm: Add array_index_nospec to guest provided index values

This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
(qemu changes not included)

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

[Xen-devel] [PATCH v2 0/2] x86/apic: improvements to disconnect_bsp_APIC

[Roger Pau Monne]

Hello,

The series contain some improvements to disconnect_bsp_APIC, which
started as a way to fix the "APIC error on CPU0: 40(00)" error printed
by some Intel boxes on reboot or shutdown. First patch is the fix for
the error, second patch is a cleanup.

Roger Pau Monne (2):
  x86/apic: fix disabling LVT0 in disconnect_bsp_APIC
  x86/apic: simplify disconnect_bsp_APIC setup of LVT{0/1}

 xen/arch/x86/apic.c | 21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

-- 
2.25.0


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

Re: [Xen-devel] [PATCH V8 1/4] x86/mm: Add array_index_nospec to guest provided index values

[Tamas K Lengyel]

On Thu, Jan 23, 2020 at 11:45 AM Andrew Cooper
 wrote:
>
> On 17/01/2020 13:31, Alexandru Stefan ISAILA wrote:
> > This patch aims to sanitize indexes, potentially guest provided
> > values, for altp2m_eptp[] and altp2m_p2m[] arrays.
> >
> > Requested-by: Jan Beulich 
> > Signed-off-by: Alexandru Isaila 
> > Acked-by: Tamas K Lengyel 
>
> Something in this series broke the ARM build.  Sorry, but I don't have
> any further time to investigate.
>
> gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
> -Wdeclaration-after-statement -Wno-unused-but-set-variable
> -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -nostdinc
> -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith
> -Wvla -pipe -D__XEN__ -include
> /builds/xen-project/xen/xen/include/xen/config.h
> '-D__OBJECT_FILE__="asm-offsets.s"' -Wa,--strip-local-absolute -g -MMD
> -MF ./.asm-offsets.s.d -mcpu=generic -mgeneral-regs-only
> -I/builds/xen-project/xen/xen/include -fno-stack-protector
> -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -S -o
> asm-offsets.s arm64/asm-offsets.c
> In file included from /builds/xen-project/xen/xen/include/asm/p2m.h:7,
>  from /builds/xen-project/xen/xen/include/asm/domain.h:7,
>  from /builds/xen-project/xen/xen/include/xen/domain.h:8,
>  from /builds/xen-project/xen/xen/include/xen/sched.h:11,
>  from arm64/asm-offsets.c:9:
> /builds/xen-project/xen/xen/include/xen/mem_access.h:61:47: error:
> 'struct p2m_domain' declared inside parameter list will not be visible
> outside of this definition or declaration [-Werror]
>  bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m,
>^~
> /builds/xen-project/xen/xen/include/xen/mem_access.h:83:38: error:
> 'struct xen_hvm_altp2m_suppress_ve_multi' declared inside parameter list

Looks like we need an explicit include for asm/p2m.h and
public/hvm/hvm_op.h in the mem_access.h header (both of which end up
being included prior to mem_access.h on an x86 build). Although from
the looks of it wrapping the _ve functions in #ifdef CONFIG_X86 ..
#endif would be even better.

Tamas

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

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

[osstest service owner]

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

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-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-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-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-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-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-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 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-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-amd64-i386-qemuu-rhel6hvm-amd  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-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 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-ws16-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-credit1   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-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   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
 test-arm64-arm64-xl   1 

Re: [Xen-devel] [PATCH V8 1/4] x86/mm: Add array_index_nospec to guest provided index values

[Andrew Cooper]

On 17/01/2020 13:31, Alexandru Stefan ISAILA wrote:
> This patch aims to sanitize indexes, potentially guest provided
> values, for altp2m_eptp[] and altp2m_p2m[] arrays.
>
> Requested-by: Jan Beulich 
> Signed-off-by: Alexandru Isaila 
> Acked-by: Tamas K Lengyel 

Something in this series broke the ARM build.  Sorry, but I don't have
any further time to investigate.

gcc -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -Wno-unused-but-set-variable
-Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -nostdinc
-fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith
-Wvla -pipe -D__XEN__ -include
/builds/xen-project/xen/xen/include/xen/config.h
'-D__OBJECT_FILE__="asm-offsets.s"' -Wa,--strip-local-absolute -g -MMD
-MF ./.asm-offsets.s.d -mcpu=generic -mgeneral-regs-only
-I/builds/xen-project/xen/xen/include -fno-stack-protector
-fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -S -o
asm-offsets.s arm64/asm-offsets.c
In file included from /builds/xen-project/xen/xen/include/asm/p2m.h:7,
 from /builds/xen-project/xen/xen/include/asm/domain.h:7,
 from /builds/xen-project/xen/xen/include/xen/domain.h:8,
 from /builds/xen-project/xen/xen/include/xen/sched.h:11,
 from arm64/asm-offsets.c:9:
/builds/xen-project/xen/xen/include/xen/mem_access.h:61:47: error:
'struct p2m_domain' declared inside parameter list will not be visible
outside of this definition or declaration [-Werror]
 bool xenmem_access_to_p2m_access(const struct p2m_domain *p2m,
   ^~
/builds/xen-project/xen/xen/include/xen/mem_access.h:83:38: error:
'struct xen_hvm_altp2m_suppress_ve_multi' declared inside parameter list
will not be visible outside of this definition or declaration [-Werror]
   struct xen_hvm_altp2m_suppress_ve_multi
*suppress_ve);
  ^~~~
cc1: all warnings being treated as errors
make[3]: *** [Makefile:124: asm-offsets.s] Error 1
make[3]: Leaving directory '/builds/xen-project/xen/xen/arch/arm'
make[2]: *** [Makefile:146: /builds/xen-project/xen/xen/xen] Error 2
make[2]: Leaving directory '/builds/xen-project/xen/xen'
make[1]: *** [Makefile:50: install] Error 2
make[1]: Leaving directory '/builds/xen-project/xen/xen'
make: *** [Makefile:130: install-xen] Error 2
make: *** Waiting for unfinished jobs

Full logs: https://gitlab.com/xen-project/xen/-/jobs/412893448

~Andrew

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

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

[Roger Pau Monne]

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.

Signed-off-by: Roger Pau Monné 
---
 xen/arch/x86/apic.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 508b1586f2..c18314c1a3 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -273,23 +273,12 @@ void disconnect_bsp_APIC(int virt_wire_setup)
 
 if (!virt_wire_setup) {
 /* For LVT0 make it edge triggered, active high, external and 
enabled */
-value = apic_read(APIC_LVT0);
-value &= ~(APIC_MODE_MASK | APIC_SEND_PENDING |
-   APIC_INPUT_POLARITY | APIC_LVT_REMOTE_IRR |
-   APIC_LVT_LEVEL_TRIGGER | APIC_LVT_MASKED );
-value |= APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING;
-value = SET_APIC_DELIVERY_MODE(value, APIC_MODE_EXTINT);
+value = APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING | APIC_DM_EXTINT;
 apic_write(APIC_LVT0, value);
 }
 
 /* For LVT1 make it edge triggered, active high, nmi and enabled */
-value = apic_read(APIC_LVT1);
-value &= ~(
-APIC_MODE_MASK | APIC_SEND_PENDING |
-APIC_INPUT_POLARITY | APIC_LVT_REMOTE_IRR |
-APIC_LVT_LEVEL_TRIGGER | APIC_LVT_MASKED);
-value |= APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING;
-value = SET_APIC_DELIVERY_MODE(value, APIC_MODE_NMI);
+value = APIC_LVT_REMOTE_IRR | APIC_SEND_PENDING | APIC_DM_NMI;
 apic_write(APIC_LVT1, value);
 }
 }
-- 
2.25.0


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

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[Andrew Cooper]

On 23/01/2020 18:15, Anthony PERARD wrote:
> On Thu, Jan 23, 2020 at 06:17:06PM +0100, Roger Pau Monné wrote:
>> On Thu, Jan 23, 2020 at 03:34:25PM +, Anthony PERARD wrote:
>>> On Tue, Jan 21, 2020 at 10:21:09AM +, Roger Pau Monné wrote:
 The issue is that this change is passing the guest domain_create_state
 to libxl__domain_build in libxl__spawn_stub_dm, and hence the
 stubdomain doesn't get created. I have the following patch that fixes
 it, but it's kind of dirty.

 ---8<---
 From 688fde95992d07bb1123d324a68006dd08bc6512 Mon Sep 17 00:00:00 2001
 From: Roger Pau Monne 
 Date: Tue, 21 Jan 2020 10:14:09 +
 Subject: [PATCH] libxl: fix stubdomain creation after aacc143006429de
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
>>> :-(, this is a lie. The email I've received has a different charset.
>> Really? The email headers also contain the same tag, and hence all my
>> emails would have a wrong encoding then.
> For emails sent by your MUA, I have:
> Content-Type: text/plain; charset="iso-8859-1"
> There's nothing wrong with that, my MUA uses the same charset. If, in the
> patch that I try to apply, I replace the content-type line of the patch
> by the one from the email header, git applied the patch just fine and
> don't complain.
>
> So, the email encoding is fine.
>
> It is just the copy of an email into another email's body that was an
> issue.
>
>>> git
>>> complained about it. Maybe next time the patch could be attached, or it
>>> could be a proper patch with some note (after ---) (git send-email can
>>> do --in-reply-to), or it could be two separated emails with the first
>>> one replying to the report and the second the patch (all in the same
>>> thread).
>> I can certainly send the patch separately as a reply as you say above,
>> but I would still need to fix my email client to set the proper
>> encoding then.
> The email I received was just fine, encoded properly (I think). It is
> just trying to apply the patch embedded into the body of the email that
> was annoying.
>
 diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
 index 3f08ccad1b..b1ddde77e8 100644
 --- a/tools/libxl/libxl_dm.c
 +++ b/tools/libxl/libxl_dm.c
 @@ -2110,17 +2110,21 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
 libxl__domain_create_state *dcs)
  xs_transaction_t t;
  
  /* convenience aliases */
 -libxl_domain_config *const dm_config = >dm_config;
  libxl_domain_config *const guest_config = sdss->dm.guest_config;
  const int guest_domid = sdss->dm.guest_domid;
  libxl__domain_build_state *const d_state = sdss->dm.build_state;
 -libxl__domain_build_state *const stubdom_state = >dm_state;
 +libxl__domain_build_state *stubdom_state;
 +libxl_domain_config *dm_config;
  
  /* Initialise private part of sdss */
 -libxl__domain_build_state_init(stubdom_state);
  dmss_init(>dm);
  dmss_init(>pvqemu);
  libxl__xswait_init(>xswait);
 +GCNEW(sdss->dcs);
 +stubdom_state = >dcs->build_state;
 +libxl__domain_build_state_init(stubdom_state);
 +GCNEW(sdss->dcs->guest_config);
 +dm_config = sdss->dcs->guest_config;
>>> I don't think that's enough, we need to initialize the dcs properly.
>>> Otherwise, libxl__domain_build() might start using thing that aren't set
>>> properly. Maybe we would need a new struct which could be pass to
>>> libxl__domain_build*, or that might be more complicated than needed.
>> Er likely yes, but creating a complete domain_create_state for the
>> stubdom will be very cumbersome I think. Maybe we can copy the one
>> from the guest over the stubdom one in order to initialize it?
> That's not going to work.
>
>> Not sure that's any better than just using an empty one.
> And an "empty one" doesn't work either, the dcs created here contains
> more that just the `build_state' and `guest_config', it also contains
> for all the _fd field set to something.
>
> The _fd thing is important because Andrew check the value of
> `restore_fd' to figure out if a domain is been restored or not.
>
> I don't have better suggestion for now, I'll try to think about it.

So I did discuss my patch being horrible in the commit message
commentary, but got an ack without any further discussion.  The structs
vs "where useful information is" map is chronically twisted.

An alternative would be to pass down an explicit "clean build" vs
"restore from serialised state" flag, which is the information actually
needed.

~Andrew

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

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[Anthony PERARD]

On Thu, Jan 23, 2020 at 06:17:06PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 23, 2020 at 03:34:25PM +, Anthony PERARD wrote:
> > On Tue, Jan 21, 2020 at 10:21:09AM +, Roger Pau Monné wrote:
> > > The issue is that this change is passing the guest domain_create_state
> > > to libxl__domain_build in libxl__spawn_stub_dm, and hence the
> > > stubdomain doesn't get created. I have the following patch that fixes
> > > it, but it's kind of dirty.
> > > 
> > > ---8<---
> > > From 688fde95992d07bb1123d324a68006dd08bc6512 Mon Sep 17 00:00:00 2001
> > > From: Roger Pau Monne 
> > > Date: Tue, 21 Jan 2020 10:14:09 +
> > > Subject: [PATCH] libxl: fix stubdomain creation after aacc143006429de
> > > MIME-Version: 1.0
> > > Content-Type: text/plain; charset=UTF-8
> > 
> > :-(, this is a lie. The email I've received has a different charset.
> 
> Really? The email headers also contain the same tag, and hence all my
> emails would have a wrong encoding then.

For emails sent by your MUA, I have:
Content-Type: text/plain; charset="iso-8859-1"
There's nothing wrong with that, my MUA uses the same charset. If, in the
patch that I try to apply, I replace the content-type line of the patch
by the one from the email header, git applied the patch just fine and
don't complain.

So, the email encoding is fine.

It is just the copy of an email into another email's body that was an
issue.

> 
> > git
> > complained about it. Maybe next time the patch could be attached, or it
> > could be a proper patch with some note (after ---) (git send-email can
> > do --in-reply-to), or it could be two separated emails with the first
> > one replying to the report and the second the patch (all in the same
> > thread).
> 
> I can certainly send the patch separately as a reply as you say above,
> but I would still need to fix my email client to set the proper
> encoding then.

The email I received was just fine, encoded properly (I think). It is
just trying to apply the patch embedded into the body of the email that
was annoying.

> > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > index 3f08ccad1b..b1ddde77e8 100644
> > > --- a/tools/libxl/libxl_dm.c
> > > +++ b/tools/libxl/libxl_dm.c
> > > @@ -2110,17 +2110,21 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
> > > libxl__domain_create_state *dcs)
> > >  xs_transaction_t t;
> > >  
> > >  /* convenience aliases */
> > > -libxl_domain_config *const dm_config = >dm_config;
> > >  libxl_domain_config *const guest_config = sdss->dm.guest_config;
> > >  const int guest_domid = sdss->dm.guest_domid;
> > >  libxl__domain_build_state *const d_state = sdss->dm.build_state;
> > > -libxl__domain_build_state *const stubdom_state = >dm_state;
> > > +libxl__domain_build_state *stubdom_state;
> > > +libxl_domain_config *dm_config;
> > >  
> > >  /* Initialise private part of sdss */
> > > -libxl__domain_build_state_init(stubdom_state);
> > >  dmss_init(>dm);
> > >  dmss_init(>pvqemu);
> > >  libxl__xswait_init(>xswait);
> > > +GCNEW(sdss->dcs);
> > > +stubdom_state = >dcs->build_state;
> > > +libxl__domain_build_state_init(stubdom_state);
> > > +GCNEW(sdss->dcs->guest_config);
> > > +dm_config = sdss->dcs->guest_config;
> > 
> > I don't think that's enough, we need to initialize the dcs properly.
> > Otherwise, libxl__domain_build() might start using thing that aren't set
> > properly. Maybe we would need a new struct which could be pass to
> > libxl__domain_build*, or that might be more complicated than needed.
> 
> Er likely yes, but creating a complete domain_create_state for the
> stubdom will be very cumbersome I think. Maybe we can copy the one
> from the guest over the stubdom one in order to initialize it?

That's not going to work.

> Not sure that's any better than just using an empty one.

And an "empty one" doesn't work either, the dcs created here contains
more that just the `build_state' and `guest_config', it also contains
for all the _fd field set to something.

The _fd thing is important because Andrew check the value of
`restore_fd' to figure out if a domain is been restored or not.

I don't have better suggestion for now, I'll try to think about it.

-- 
Anthony PERARD

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

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

[Roger Pau Monne]

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é 
---
Changes since v1:
 - Use clear_local_APIC in order to clear LINT0.
---
 xen/arch/x86/apic.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index a6a7754d77..508b1586f2 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -262,6 +262,8 @@ void disconnect_bsp_APIC(int virt_wire_setup)
 /* Go back to Virtual Wire compatibility mode */
 unsigned long value;
 
+clear_local_APIC();
+
 /* For the spurious interrupt use vector F, and enable it */
 value = apic_read(APIC_SPIV);
 value &= ~APIC_VECTOR_MASK;
@@ -279,10 +281,6 @@ void disconnect_bsp_APIC(int virt_wire_setup)
 value = SET_APIC_DELIVERY_MODE(value, APIC_MODE_EXTINT);
 apic_write(APIC_LVT0, value);
 }
-else {
-/* Disable LVT0 */
-apic_write(APIC_LVT0, APIC_LVT_MASKED);
-}
 
 /* For LVT1 make it edge triggered, active high, nmi and enabled */
 value = apic_read(APIC_LVT1);
-- 
2.25.0


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

Re: [Xen-devel] Valgrind support upgraded to Xen 4.13

[Andrew Cooper]

On 23/01/2020 17:45, Tamas K Lengyel wrote:
> Hi all,
> I just wanted to bring it to the community's attention that I've upped
> Valgrind's Xen support to include everything up to Xen 4.13. It's now
> merged and will be part of the next Valgrind release:
> https://sourceware.org/git/?p=valgrind.git;a=commit;h=c88133141a354d65568fb85037abc5e1f74ce46b

TYVM.

Hopefully this will all become far more rational when we switch to
stable ABIs.  I'd forgotten this from the list of "why unstable ABIs are
real problem in practice".

~Andrew

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

[Xen-devel] Valgrind support upgraded to Xen 4.13

[Tamas K Lengyel]

Hi all,
I just wanted to bring it to the community's attention that I've upped
Valgrind's Xen support to include everything up to Xen 4.13. It's now
merged and will be part of the next Valgrind release:
https://sourceware.org/git/?p=valgrind.git;a=commit;h=c88133141a354d65568fb85037abc5e1f74ce46b

Cheers,
Tamas

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

Re: [Xen-devel] [PATCH v5 15/18] xen/mem_sharing: VM forking

[Tamas K Lengyel]

On Thu, Jan 23, 2020 at 10:21 AM George Dunlap  wrote:
>
> On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> > 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 
>
> Overall this looks really good.  Just a few questions.
>
> > ---
> >  xen/arch/x86/domain.c |   9 ++
> >  xen/arch/x86/hvm/hvm.c|   2 +-
> >  xen/arch/x86/mm/mem_sharing.c | 220 ++
> >  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, 265 insertions(+), 4 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 28fefa1f81..953abcc1fc 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -2198,6 +2198,15 @@ 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.
> > + */
> > +if ( d->parent )
> > +{
> > +domain_unpause(d->parent);
> > +d->parent = NULL;
>
> Did this want to be `if ( d->parent_paused )`?

If the domain has the parent pointer set, it's guaranteed that the
parent is paused. It's paused before the parent pointer is set during
the fork hypercall.

>
> > +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 ( !vcpu_create(cd, i) )
> > +return -EINVAL;
>
> You're not copying the contents of the vcpu registers or anything here
> -- is that something you're leaving to your dom0 agent?

The registers are being copied as part of the HVM contexts.

>
> > +static int mem_sharing_fork(struct domain *d, struct domain *cd)
> > +{
> > +int rc = -EINVAL;
> > +
> > +if ( !cd->controller_pause_count )
> > +return rc;
> > +
> > +/*
> > + * We only want to pause the parent once, not each time this
> > + * operation is restarted due to preemption.
> > + */
> > +if ( !cd->parent_paused )
> > +{
> > +domain_pause(d);
> > +cd->parent_paused = true;
> > +}
> > +
> > +cd->max_pages = d->max_pages;
> > +cd->max_vcpus = d->max_vcpus;
> > +
> > +/* this is preemptible so it's the first to get done */
> > +if ( (rc = fork_hap_allocation(d, cd)) )
> > +goto done;
> > +
> > +if ( (rc = bring_up_vcpus(cd, d->cpupool)) )
> > +goto done;
> > +
> > +if ( (rc = hvm_copy_context_and_params(d, cd)) )
> > +goto done;
> > +
> > +fork_tsc(d, cd);
> > +
> > +cd->parent = d;
>
> What happens if the parent dies?
>
> It seems like we might want to do get_domain(parent) here, and
> put_domain(parent) in domain_destroy.

If forks are still active when someone destroys the parent than Xen
will crash I assume. Right now it's a requirement that the parent
remains in existence - and it's paused - while there are forks active.
We enforce the pause state but making the parent undestroyable is not
implemented right now. We just trust that the user of this
experimental system won't do that.

But yes, doing the get_domain()/put_domain() dance would be an easy
way to do that. Will add that and then we don't have to worry about
the parent getting pulled from under our feat.

>
> I'll probably need to come back to this, at which point I may have more
> questions.

Thanks!
Tamas

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

Re: [Xen-devel] [PATCH v5 15/18] xen/mem_sharing: VM forking

[George Dunlap]

On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> 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 

Overall this looks really good.  Just a few questions.

> ---
>  xen/arch/x86/domain.c |   9 ++
>  xen/arch/x86/hvm/hvm.c|   2 +-
>  xen/arch/x86/mm/mem_sharing.c | 220 ++
>  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, 265 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 28fefa1f81..953abcc1fc 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2198,6 +2198,15 @@ 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.
> + */
> +if ( d->parent )
> +{
> +domain_unpause(d->parent);
> +d->parent = NULL;

Did this want to be `if ( d->parent_paused )`?

> +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 ( !vcpu_create(cd, i) )
> +return -EINVAL;

You're not copying the contents of the vcpu registers or anything here
-- is that something you're leaving to your dom0 agent?

> +static int mem_sharing_fork(struct domain *d, struct domain *cd)
> +{
> +int rc = -EINVAL;
> +
> +if ( !cd->controller_pause_count )
> +return rc;
> +
> +/*
> + * We only want to pause the parent once, not each time this
> + * operation is restarted due to preemption.
> + */
> +if ( !cd->parent_paused )
> +{
> +domain_pause(d);
> +cd->parent_paused = true;
> +}
> +
> +cd->max_pages = d->max_pages;
> +cd->max_vcpus = d->max_vcpus;
> +
> +/* this is preemptible so it's the first to get done */
> +if ( (rc = fork_hap_allocation(d, cd)) )
> +goto done;
> +
> +if ( (rc = bring_up_vcpus(cd, d->cpupool)) )
> +goto done;
> +
> +if ( (rc = hvm_copy_context_and_params(d, cd)) )
> +goto done;
> +
> +fork_tsc(d, cd);
> +
> +cd->parent = d;

What happens if the parent dies?

It seems like we might want to do get_domain(parent) here, and
put_domain(parent) in domain_destroy.

I'll probably need to come back to this, at which point I may have more
questions.

 -George

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

Re: [Xen-devel] [PATCH v5 14/18] x86/mem_sharing: use default_access in add_to_physmap

[Tamas K Lengyel]

On Thu, Jan 23, 2020 at 9:44 AM George Dunlap  wrote:
>
> On 1/22/20 5:08 PM, Tamas K Lengyel wrote:
> > On Wed, Jan 22, 2020 at 8:35 AM Jan Beulich  wrote:
> >>
> >> On 21.01.2020 18:49, Tamas K Lengyel wrote:
> >>> 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,
> >>
> >> "can be" is too vague for my taste - it suggests there may also be cases
> >> where a sensible value is returned, and hence it should be used. Could
> >> you clarify this please? (The code change itself of course is simple and
> >> mechanical enough to look okay.)
> >
> > Well, I can only speak of what I observed. The case seems to be that
> > most of the time the function actually returns p2m_access_rwx (which
> > is sensible), but occasionally something else. I didn't investigate
> > where that value actually comes from, but when populating a physmap
> > like this only the default_access is sane.
>
> It would be good to get to the bottom of this.  Is it possible that your
> dom0 agent (or whatever it's called) is calling add_to_physmap() on gfns
> that have already been populated?  Is that something you want to catch?
>

OK, I went back and deciphered why sometimes I saw different permissions here.

In the context I ran into this issue there is no dom0 agent calling
add_to_physmap. We wind up in this path with a VM fork where the MMU
faulted. The fault handler is trying to determine whether the page
needs to be forked from its parent: populated with a shared entry if
it's R/X access, or deduplicated if it's a W. This forking only
actually happens if the page type that is returned by ept_get_entry is
of a hole type. When it's a hole type, ept_get_entry always returns
p2m_access_n as the access permission. Copying that access permission
to the newly populated entry is bad - that's what this patch fixes.

But this path also gets hit when the MMU faults for other reasons. In
those cases will get permissions other then p2m_access_n since the
type is not a hole. But when it's not a hole, this function bails as
that's a clear signal that the page doesn't need forking. So I was
seeing p2m_access_rwx permission for page accesses that triggered the
MMU fault for reasons other then mem_access. For example, when a
previously shared entry needs unsharing.

So there is no mystery after all, I was just printing my debug lines
with the mem_access permissions irrespective of the page type before
the path bails due to the type check.

Tamas

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

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[Roger Pau Monné]

On Thu, Jan 23, 2020 at 03:34:25PM +, Anthony PERARD wrote:
> On Tue, Jan 21, 2020 at 10:21:09AM +, Roger Pau Monné wrote:
> > The issue is that this change is passing the guest domain_create_state
> > to libxl__domain_build in libxl__spawn_stub_dm, and hence the
> > stubdomain doesn't get created. I have the following patch that fixes
> > it, but it's kind of dirty.
> > 
> > ---8<---
> > From 688fde95992d07bb1123d324a68006dd08bc6512 Mon Sep 17 00:00:00 2001
> > From: Roger Pau Monne 
> > Date: Tue, 21 Jan 2020 10:14:09 +
> > Subject: [PATCH] libxl: fix stubdomain creation after aacc143006429de
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> 
> :-(, this is a lie. The email I've received has a different charset.

Really? The email headers also contain the same tag, and hence all my
emails would have a wrong encoding then.

> git
> complained about it. Maybe next time the patch could be attached, or it
> could be a proper patch with some note (after ---) (git send-email can
> do --in-reply-to), or it could be two separated emails with the first
> one replying to the report and the second the patch (all in the same
> thread).

I can certainly send the patch separately as a reply as you say above,
but I would still need to fix my email client to set the proper
encoding then.

> 
> > Content-Transfer-Encoding: 8bit
> > 
> > aacc143006429de broke stubdomain creation by passing the guest
> > domain_create_state to libxl__domain_build in libxl__spawn_stub_dm,
> > when it should instead be crafting a new domain_create_state for the
> > stubdomain.
> > 
> > Fixes: aacc143006429de ('tools/libxl: Plumb domain_create_state down into 
> > libxl__build_pre()')
> > Signed-off-by: Roger Pau Monné 
> > ---
> >  tools/libxl/libxl_dm.c   | 22 +-
> >  tools/libxl/libxl_internal.h |  3 +--
> >  2 files changed, 14 insertions(+), 11 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index 3f08ccad1b..b1ddde77e8 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -2110,17 +2110,21 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
> > libxl__domain_create_state *dcs)
> >  xs_transaction_t t;
> >  
> >  /* convenience aliases */
> > -libxl_domain_config *const dm_config = >dm_config;
> >  libxl_domain_config *const guest_config = sdss->dm.guest_config;
> >  const int guest_domid = sdss->dm.guest_domid;
> >  libxl__domain_build_state *const d_state = sdss->dm.build_state;
> > -libxl__domain_build_state *const stubdom_state = >dm_state;
> > +libxl__domain_build_state *stubdom_state;
> > +libxl_domain_config *dm_config;
> >  
> >  /* Initialise private part of sdss */
> > -libxl__domain_build_state_init(stubdom_state);
> >  dmss_init(>dm);
> >  dmss_init(>pvqemu);
> >  libxl__xswait_init(>xswait);
> > +GCNEW(sdss->dcs);
> > +stubdom_state = >dcs->build_state;
> > +libxl__domain_build_state_init(stubdom_state);
> > +GCNEW(sdss->dcs->guest_config);
> > +dm_config = sdss->dcs->guest_config;
> 
> I don't think that's enough, we need to initialize the dcs properly.
> Otherwise, libxl__domain_build() might start using thing that aren't set
> properly. Maybe we would need a new struct which could be pass to
> libxl__domain_build*, or that might be more complicated than needed.

Er likely yes, but creating a complete domain_create_state for the
stubdom will be very cumbersome I think. Maybe we can copy the one
from the guest over the stubdom one in order to initialize it?

Not sure that's any better than just using an empty one.

> >  
> >  if (guest_config->b_info.device_model_version !=
> >  LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index d919f91882..abf88dfd76 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -4102,8 +4102,7 @@ typedef struct {
> >  /* filled in by user, must remain valid: */
> >  libxl__dm_spawn_cb *callback; /* called as callback(,>dm,) */
> >  /* private to libxl__spawn_stub_dm: */
> > -libxl_domain_config dm_config;
> > -libxl__domain_build_state dm_state;
> > +libxl__domain_create_state *dcs;
> 
> This should be named dm_dcs, I think, to follow the same pattern as
> before.

Sure.

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] 146420: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 xen  2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
baseline version:
 xen  021cc01ecac111be3301ad33ff5cda4543ca8b92

Last test of basis   146401  2020-01-22 23:00:35 Z0 days
Testing same since   146420  2020-01-23 15:00:29 Z0 days1 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  George Dunlap 
  Jan Beulich 
  Tamas K Lengyel 

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


Not pushing.


commit 2aa977eb6baaa4e43a9ef3ad26f9eb117eb178f5
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:33 2020 +

x86/mm: Make use of the default access param from xc_altp2m_create_view

At this moment the default_access param from xc_altp2m_create_view is
not used.

This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.

Signed-off-by: Alexandru Isaila 
Acked-by: Jan Beulich 
Acked-by: Tamas K Lengyel 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit b701adbee37befa58c7bdec80b65f93e033252e6
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:31 2020 +

x86/mm: Pull vendor-independent altp2m code out of p2m-ept.c and into p2m.c

No functional changes.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit ea22bcd030da771be18821bf4a898ed7a314eb83
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:30 2020 +

x86/altp2m: Add hypercall to set a range of sve bits

By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not break in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for continuation is made in order to have
preemption on large ranges.
The gfn of the first error is stored in
xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
If no error occurred the values will be 0.

Signed-off-by: Alexandru Isaila 
Reviewed-by: Jan Beulich 
Reviewed-by: Petre Pircalabu 
Acked-by: George Dunlap 

commit 5160dbd512523d865f7271af23636aa3f3536186
Author: Alexandru Stefan ISAILA 
Date:   Fri Jan 17 13:31:26 2020 +

x86/mm: Add array_index_nospec to guest provided index values

This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.

Requested-by: Jan Beulich 
Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
(qemu changes not included)

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

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

[osstest service owner]

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

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 146354 
pass in 146414
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail pass in 146354
 test-amd64-amd64-libvirt-vhd 18 guest-start.2  fail pass in 146398
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 146398

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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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
 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 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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 linux

[Xen-devel] [XEN PATCH] libxl: Fix comment about dcs.sdss

[Anthony PERARD]

The field 'sdss' was named 'dmss' before, commit 3148bebbf0ab did the
renamed but didn't update the comment.

Fixes: 3148bebbf0ab ("libxl: rename a field in libxl__domain_create_state")
Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d919f918826d..387e7a6a860d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4144,7 +4144,7 @@ struct libxl__domain_create_state {
 libxl__checkpoint_devices_state cds;
 libxl__bootloader_state bl;
 libxl__stub_dm_spawn_state sdss;
-/* If we're not doing stubdom, we use only dmss.dm,
+/* If we're not doing stubdom, we use only sdss.dm,
  * for the non-stubdom device model. */
 libxl__stream_read_state srs;
 /* necessary if the domain creation failed and we have to destroy it */
-- 
Anthony PERARD


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

Re: [Xen-devel] [PATCH v5 10/18] x86/mem_sharing: Convert MEM_SHARING_DESTROY_GFN to a bool

[Jan Beulich]

On 23.01.2020 17:42, George Dunlap wrote:
> On 1/23/20 4:37 PM, Jan Beulich wrote:
>> On 23.01.2020 17:32, George Dunlap wrote:
>>> On 1/23/20 4:23 PM, Tamas K Lengyel wrote:
 On Thu, Jan 23, 2020 at 9:14 AM George Dunlap  
 wrote:
>
> On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
>> MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
>> However, the bitfield is not used for anything else, so just convert it 
>> to a
>> bool instead.
>>
>> Signed-off-by: Tamas K Lengyel 
>> Reviewed-by: Jan Beulich 
>
> But is there a particular advantage to getting rid of the bitfield?
>
> You're the maintainer, so it's your decision of course.  But if it were
> me I'd leave it as a bitfield so that all the bitfield code is there if
> it's needed in the future.  Flipping it to a bool, with the risk of
> flipping it back to a bitfield later, seems like pointless churn to me.
>
> (Although perhaps the reason will become evident by the time I get to
> the end of the series.)

 Provided its been many years since this code has been added with no
 need for any extra bits, and with no expectations that this would
 change any time soon, I wouldn't worry about that. True, there is very
 little difference between keeping the code as-is vs converting it to
 bool, but IMHO it makes the code easier to follow without you
 wondering what might be those non-existent situations that warranted
 it to be a bitmap to begin with.
>>>
>>> It's definitely a judgement call, and I can see where you're coming
>>> from.  Like I said, if it were me I'd leave it, but it's not. :-)   Just
>>> wanted to raise the issue as I was going through.  I'd Ack it but you've
>>> already got an R-b.
>>
>> Until your proposal gets accepted, isn't it that your ack is needed
>> despite the R-b? This is also why e.g. for patch 2 I didn't see a
>> point in sending any R-b, as the patch will need your ack anyway,
>> and it's so simple that "reviewed" would be an overstatement.
> 
> I don't think I'm co-maintainer of this; and you're a less-specific
> maintainer than Tamas, right?  Do you need my Ack?

Well, I was under the impression that the maintainership nesting
was hierarchical, i.e. the next level up would become the relevant
one in cases like this one. But I'm of course happy to commit the
parts of this series which are ready, if just any less specific
maintainer's ack is sufficient. Probably tomorrow morning then.

Jan

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

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

[osstest service owner]

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

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 9a1f14ad721bbcd833ec5108944c44a502392f03
baseline version:
 ovmf 70911f1f4aee0366b6122f2b90d367ec0f066beb

Last test of basis   145767  2020-01-08 00:39:09 Z   15 days
Failing since145774  2020-01-08 02:50:20 Z   15 days   57 attempts
Testing same since   146346  2020-01-21 04:31:27 Z2 days9 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 1164 lines long.)

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

Re: [Xen-devel] [PATCH v5 14/18] x86/mem_sharing: use default_access in add_to_physmap

[George Dunlap]

On 1/22/20 5:08 PM, Tamas K Lengyel wrote:
> On Wed, Jan 22, 2020 at 8:35 AM Jan Beulich  wrote:
>>
>> On 21.01.2020 18:49, Tamas K Lengyel wrote:
>>> 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,
>>
>> "can be" is too vague for my taste - it suggests there may also be cases
>> where a sensible value is returned, and hence it should be used. Could
>> you clarify this please? (The code change itself of course is simple and
>> mechanical enough to look okay.)
> 
> Well, I can only speak of what I observed. The case seems to be that
> most of the time the function actually returns p2m_access_rwx (which
> is sensible), but occasionally something else. I didn't investigate
> where that value actually comes from, but when populating a physmap
> like this only the default_access is sane.

It would be good to get to the bottom of this.  Is it possible that your
dom0 agent (or whatever it's called) is calling add_to_physmap() on gfns
that have already been populated?  Is that something you want to catch?

 -George

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

Re: [Xen-devel] [PATCH v5 10/18] x86/mem_sharing: Convert MEM_SHARING_DESTROY_GFN to a bool

[George Dunlap]

On 1/23/20 4:37 PM, Jan Beulich wrote:
> On 23.01.2020 17:32, George Dunlap wrote:
>> On 1/23/20 4:23 PM, Tamas K Lengyel wrote:
>>> On Thu, Jan 23, 2020 at 9:14 AM George Dunlap  
>>> wrote:

 On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
> However, the bitfield is not used for anything else, so just convert it 
> to a
> bool instead.
>
> Signed-off-by: Tamas K Lengyel 
> Reviewed-by: Jan Beulich 

 But is there a particular advantage to getting rid of the bitfield?

 You're the maintainer, so it's your decision of course.  But if it were
 me I'd leave it as a bitfield so that all the bitfield code is there if
 it's needed in the future.  Flipping it to a bool, with the risk of
 flipping it back to a bitfield later, seems like pointless churn to me.

 (Although perhaps the reason will become evident by the time I get to
 the end of the series.)
>>>
>>> Provided its been many years since this code has been added with no
>>> need for any extra bits, and with no expectations that this would
>>> change any time soon, I wouldn't worry about that. True, there is very
>>> little difference between keeping the code as-is vs converting it to
>>> bool, but IMHO it makes the code easier to follow without you
>>> wondering what might be those non-existent situations that warranted
>>> it to be a bitmap to begin with.
>>
>> It's definitely a judgement call, and I can see where you're coming
>> from.  Like I said, if it were me I'd leave it, but it's not. :-)   Just
>> wanted to raise the issue as I was going through.  I'd Ack it but you've
>> already got an R-b.
> 
> Until your proposal gets accepted, isn't it that your ack is needed
> despite the R-b? This is also why e.g. for patch 2 I didn't see a
> point in sending any R-b, as the patch will need your ack anyway,
> and it's so simple that "reviewed" would be an overstatement.

I don't think I'm co-maintainer of this; and you're a less-specific
maintainer than Tamas, right?  Do you need my Ack?

I'm happy to go back and Ack all the mm/ ones you've given an R-b to up
until this point in the series; I just didn't think it was necessary.

I'll probably Ack patch 2 once I become convinced the change in that
patch is necessary (which I'm guessing might be when I get to 15/18).

 -George

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

Re: [Xen-devel] [PATCH v5 10/18] x86/mem_sharing: Convert MEM_SHARING_DESTROY_GFN to a bool

[Jan Beulich]

On 23.01.2020 17:32, George Dunlap wrote:
> On 1/23/20 4:23 PM, Tamas K Lengyel wrote:
>> On Thu, Jan 23, 2020 at 9:14 AM George Dunlap  
>> wrote:
>>>
>>> On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
 MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
 However, the bitfield is not used for anything else, so just convert it to 
 a
 bool instead.

 Signed-off-by: Tamas K Lengyel 
 Reviewed-by: Jan Beulich 
>>>
>>> But is there a particular advantage to getting rid of the bitfield?
>>>
>>> You're the maintainer, so it's your decision of course.  But if it were
>>> me I'd leave it as a bitfield so that all the bitfield code is there if
>>> it's needed in the future.  Flipping it to a bool, with the risk of
>>> flipping it back to a bitfield later, seems like pointless churn to me.
>>>
>>> (Although perhaps the reason will become evident by the time I get to
>>> the end of the series.)
>>
>> Provided its been many years since this code has been added with no
>> need for any extra bits, and with no expectations that this would
>> change any time soon, I wouldn't worry about that. True, there is very
>> little difference between keeping the code as-is vs converting it to
>> bool, but IMHO it makes the code easier to follow without you
>> wondering what might be those non-existent situations that warranted
>> it to be a bitmap to begin with.
> 
> It's definitely a judgement call, and I can see where you're coming
> from.  Like I said, if it were me I'd leave it, but it's not. :-)   Just
> wanted to raise the issue as I was going through.  I'd Ack it but you've
> already got an R-b.

Until your proposal gets accepted, isn't it that your ack is needed
despite the R-b? This is also why e.g. for patch 2 I didn't see a
point in sending any R-b, as the patch will need your ack anyway,
and it's so simple that "reviewed" would be an overstatement.

Jan

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

Re: [Xen-devel] [PATCH v5 10/18] x86/mem_sharing: Convert MEM_SHARING_DESTROY_GFN to a bool

[George Dunlap]

On 1/23/20 4:23 PM, Tamas K Lengyel wrote:
> On Thu, Jan 23, 2020 at 9:14 AM George Dunlap  
> wrote:
>>
>> On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
>>> MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
>>> However, the bitfield is not used for anything else, so just convert it to a
>>> bool instead.
>>>
>>> Signed-off-by: Tamas K Lengyel 
>>> Reviewed-by: Jan Beulich 
>>
>> But is there a particular advantage to getting rid of the bitfield?
>>
>> You're the maintainer, so it's your decision of course.  But if it were
>> me I'd leave it as a bitfield so that all the bitfield code is there if
>> it's needed in the future.  Flipping it to a bool, with the risk of
>> flipping it back to a bitfield later, seems like pointless churn to me.
>>
>> (Although perhaps the reason will become evident by the time I get to
>> the end of the series.)
> 
> Provided its been many years since this code has been added with no
> need for any extra bits, and with no expectations that this would
> change any time soon, I wouldn't worry about that. True, there is very
> little difference between keeping the code as-is vs converting it to
> bool, but IMHO it makes the code easier to follow without you
> wondering what might be those non-existent situations that warranted
> it to be a bitmap to begin with.

It's definitely a judgement call, and I can see where you're coming
from.  Like I said, if it were me I'd leave it, but it's not. :-)   Just
wanted to raise the issue as I was going through.  I'd Ack it but you've
already got an R-b.

 -George

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

Re: [Xen-devel] [RFC PATCH V2 11/11] x86: tsc: avoid system instability in hibernation

[Boris Ostrovsky]

On 1/22/20 3:07 PM, Anchal Agarwal wrote:
>> In this case tsc_verify_tsc_adjust(true) this does nothing as
>> feature bit X86_FEATURE_TSC_ADJUST is not available to guest. 


Is it not available to your specific guest? Because AFAICT it is
available in general (to HVM/PVH guests).


> 4. Also, the instances do not have InvariantTSC exposed.

If you specify "nomigrate=true" in your configuration file you should
have that feature enabled.


-boris


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

Re: [Xen-devel] [PATCH v5 10/18] x86/mem_sharing: Convert MEM_SHARING_DESTROY_GFN to a bool

[Tamas K Lengyel]

On Thu, Jan 23, 2020 at 9:14 AM George Dunlap  wrote:
>
> On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> > MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
> > However, the bitfield is not used for anything else, so just convert it to a
> > bool instead.
> >
> > Signed-off-by: Tamas K Lengyel 
> > Reviewed-by: Jan Beulich 
>
> But is there a particular advantage to getting rid of the bitfield?
>
> You're the maintainer, so it's your decision of course.  But if it were
> me I'd leave it as a bitfield so that all the bitfield code is there if
> it's needed in the future.  Flipping it to a bool, with the risk of
> flipping it back to a bitfield later, seems like pointless churn to me.
>
> (Although perhaps the reason will become evident by the time I get to
> the end of the series.)

Provided its been many years since this code has been added with no
need for any extra bits, and with no expectations that this would
change any time soon, I wouldn't worry about that. True, there is very
little difference between keeping the code as-is vs converting it to
bool, but IMHO it makes the code easier to follow without you
wondering what might be those non-existent situations that warranted
it to be a bitmap to begin with.

Tamas

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

Re: [Xen-devel] [PATCH v2] cmdline: treat hyphens and underscores the same

[Andrew Cooper]

On 23/01/2020 11:42, Jan Beulich wrote:
> In order to avoid permanently having to ask that no new command line
> options using underscores be introduced (albeit I'm likely to still make
> remarks), and in order to also allow extending the use of hyphens to
> pre-existing ones, introduce custom comparison functions treating both
> characters as matching.
>
> Signed-off-by: Jan Beulich 
> ---
> v2: Rename to opt_str{,n}cmp(). Don't use the new function for comapring
> against "no-" in parse_params(). Add comment to cdiff().

Personally, I think this is a bad idea and should not be continued.

Yes - it is irritating needing to remember whether an option is spelled
with hyphen or underscore, but that is nothing compared to the pain for
users, who will have less bleeding edge version of Xen where the
different really matters.

Having one consistent behaviour across all versions of Xen is of far
more value to people than trying to fix a few wonky corner cases for
developers benefit.

~Andrew

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

Re: [Xen-devel] [PATCH v5 10/18] x86/mem_sharing: Convert MEM_SHARING_DESTROY_GFN to a bool

[George Dunlap]

On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> MEM_SHARING_DESTROY_GFN is used on the 'flags' bitfield during unsharing.
> However, the bitfield is not used for anything else, so just convert it to a
> bool instead.
> 
> Signed-off-by: Tamas K Lengyel 
> Reviewed-by: Jan Beulich 

But is there a particular advantage to getting rid of the bitfield?

You're the maintainer, so it's your decision of course.  But if it were
me I'd leave it as a bitfield so that all the bitfield code is there if
it's needed in the future.  Flipping it to a bool, with the risk of
flipping it back to a bitfield later, seems like pointless churn to me.

(Although perhaps the reason will become evident by the time I get to
the end of the series.)

 -George

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

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

[osstest service owner]

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

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-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  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-i386-xsm  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-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  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-amd64-amd64-xl-qemuu-debianhvm-i386-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  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
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   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-shadow1 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-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 

Re: [Xen-devel] [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

[Jan Beulich]

On 23.01.2020 16:56, Durrant, Paul wrote:
>> From: Jan Beulich 
>> Sent: 23 January 2020 15:32
>>
>> On 23.01.2020 15:03, Paul Durrant wrote:
>>> vmx_alloc_vlapic_mapping() currently contains some very odd looking code
>>> that allocates a MEMF_no_owner domheap page and then shares with the
>> guest
>>> as if it were a xenheap page. This then requires
>> vmx_free_vlapic_mapping()
>>> to call a special function in the mm code: free_shared_domheap_page().
>>>
>>> By using a 'normal' domheap page (i.e. by not passing MEMF_no_owner to
>>> alloc_domheap_page()), the odd looking code in
>> vmx_alloc_vlapic_mapping()
>>> can simply use get_page_and_type() to set up a writable mapping before
>>> insertion in the P2M and vmx_free_vlapic_mapping() can simply release
>> the
>>> page using put_page_alloc_ref() followed by put_page_and_type(). This
>>> then allows free_shared_domheap_page() to be purged.
>>>
>>> There is, however, some fall-out from this simplification:
>>>
>>> - alloc_domheap_page() will now call assign_pages() and run into the
>> fact
>>>   that 'max_pages' is not set until some time after domain_create(). To
>>>   avoid an allocation failure, domain_create() is modified to set
>>>   max_pages to an initial value, sufficient to cover any domheap
>>>   allocations required to complete domain creation. The value will be
>>>   set to the 'real' max_pages when the tool-stack later performs the
>>>   XEN_DOMCTL_max_mem operation, thus allowing the rest of the domain's
>>>   memory to be allocated.
>>
>> I continue to disagree with this approach, and I don't think I've
>> heard back on the alternative suggestion of using MEMF_no_refcount
>> instead of MEMF_no_owner.
> 
> I responded in v1:
> 
> "
>> Did you consider passing MEMF_no_refcount here, to avoid the
>> fiddling with assign_pages()? That'll in particular also
>> avoid ...
>>
> 
> You remember what happened last time we did that (with the ioreq
> server page), right? That's why assign_pages() vetoes non-refcounted
> pages.
> "

Interesting - this mail appears to never have reached me. I'm
sorry for implying you didn't reply.

>> As said before, the page (and any other
>> ones up to DOMAIN_INIT_PAGES, which I find rather fragile to be
>> set to 1) will now get accounted against the amount allowed for
>> the domain to allocate.
>>
>> It also looks to me as if this will break e.g.
>> p2m_pod_set_mem_target(), which at the very top has
>>
>> /* P == B: Nothing to do (unless the guest is being created). */
>> populated = d->tot_pages - p2m->pod.count;
>> if ( populated > 0 && p2m->pod.entry_count == 0 )
>> goto out;
>>
>> This code assumes that during domain creation all pages recorded
>> in ->tot_pages have also been recorded in ->pod.count.
>>
>> There may be other uses of ->tot_pages which this change conflicts
>> with.
>>
>>> - Because the domheap page is no longer a pseudo-xenheap page, the
>>>   reference counting will prevent the domain from being destroyed. Thus
>>>   the call to vmx_free_vlapic_mapping() is moved from the
>>>   domain_destroy() method into the domain_relinquish_resources() method.
>>>   Whilst in the area, make the domain_destroy() method an optional
>>>   alternative_vcall() (since it will no longer peform any function in
>> VMX
>>>   and is stubbed in SVM anyway).
>>
>> All of this would, afaict, become irrelevant when using MEMF_no_refcount.
>>
>> There looks to be one issue (which I think we have been discussing
>> before): By not bumping ->tot_pages, its decrementing upon freeing
>> the page will be a problem.
> 
> Yes, that's exactly the problem with assigning MEMF_no_refcount
> pages, which is way it is outlawed.

Outlawed? It's being special treated, but nothing more/worse.

>> I can see two possible solutions to this:
>> - Introduce a flag indicating there should also be no accounting
>>   upon freeing of the page.
> 
> What sort of flag did you have in mind? Do we have space anywhere
> in type-info or count-info to put it? If we can make assigning
> non-refcounted pages safe then it's certainly an attractive option.

Stealing a bit from PGC_count_mask would likely be the way to go,
unless we can figure a PGC_* bit which can safely be overloaded.
Type-info wouldn't be the right place, I guess.

>> - Instead of avoiding to increment ->tot_pages, _also_ increment
>>   ->max_pages. The interaction with XEN_DOMCTL_max_mem will then of
>>   course be, well, interesting.
>>
> 
> Indeed, which is why I opted for the simple approach. As I've said in
> other responses, max_pages ought be set by the toolstack when the
> domain is created so I wanted to come up with something that's not
> too invasive until that change is made so if the pages do need to be
> ref-counted then I guess I'll have to figure out how to make the
> initial allocation co-exist with PoD.

I'd suggest you don't even try to. The interaction with PoD was just
the example I could easily think of because of having touched PoD
code recently. 

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

[Andrew Cooper]

On 23/01/2020 05:19, Bobby Eshleman wrote:
> On Wed, Jan 22, 2020 at 02:57:47PM +, Andrew Cooper wrote:
>> How much time do you have to put towards the port?  Is this something in
>> your free time, or something you are doing as part of work?  Ultimately,
>> we are going to need to increase the level of RISC-V knowledge in the
>> community to maintain things in the future.
>>
> This is something in my free time, and I have about 20 hours a week to
> put into it.

Ok, so not full time, but hopefully enough time to help spread some
knowledge.

>
>> Other than that, very RFC series are entirely fine.  A good first step
>> would be simply to get the build working, and get some kind of
>> cross-compile build in CI, to make sure that we don't clobber the RISC-V
>> build with common or other-arch changes.
>>
> That's something I can look at, if the idea of QEMU in CI is
> not too horrific.

We have https://gitlab.com/xen-project/xen/pipelines which runs a load
of containerised builds.  How easy is it to set up a containerised
RISC-V cross-compiler environment?

The test step also boots Xen under Qemu software emulation to check that
we don't have any boot-time screamers.  A reasonable second step might
be to have start_xen() panic() at the end, and check for that in the
console log, which would allow for some kind of boot testing before
getting all the way to "and here is dom0 ready to run".

All configuration is in .gitlab-ci.yml and automation/.

~Andrew

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

Re: [Xen-devel] [PATCH v5 07/18] x86/mem_sharing: define mem_sharing_domain to hold some scattered variables

[George Dunlap]

On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> Create struct mem_sharing_domain under hvm_domain and move mem sharing
> variables into it from p2m_domain and hvm_domain.
> 
> Expose the mem_sharing_enabled macro to be used consistently across Xen.
> 
> Remove some duplicate calls to mem_sharing_enabled in mem_sharing.c
> 
> Signed-off-by: Tamas K Lengyel 
> Acked-by: Jan Beulich 

Acked-by: George Dunlap 

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

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

[Jan Beulich]

On 23.01.2020 16:43, Roger Pau Monné wrote:
> On Fri, Jan 17, 2020 at 05:25:12PM +0100, Jan Beulich wrote:
>> On 17.01.2020 17:08, Roger Pau Monné wrote:
>>> On Fri, Jan 17, 2020 at 04:56:00PM +0100, Jan Beulich wrote:
 On 17.01.2020 16:09, 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.

 But there are many more instances where we (have a risk to) do so,
 most notably in clear_local_APIC(). The two step logic there is
 anyway somewhat in conflict with the citation above.
>>>
>>> clear_local_APIC masks the error vector before doing any write, and
>>> clears ESR afterwards, there's a comment at the top:
>>>
>>> "Masking an LVT entry on a P6 can trigger a local APIC error
>>> if the vector is zero. Mask LVTERR first to prevent this."
>>>
>>> We could do the same (ie: mask LVTERR first and clear ESR afterwards)
>>> if that seems preferable. There's a maxlvt check in clear_local_APIC,
>>> but the sdm doesn't specify anyway to check if the lapic will accept a
>>> masked vector 0 write or not, so not sure whether we should replicate
>>> that check or just do it unconditionally on both disconnect_bsp_APIC
>>> and clear_local_APIC.
>>
>> I think doing it the most careful way is going to be best. I find it
>> surprising anyway that disconnect_bsp_APIC() doesn't write LVTERR
>> (or other LVTs except for LVT1) at all. The function looks to have a
>> goal of putting the APIC back into the state that we found it when
>> booting.
> 
> Maybe it would be better to just call clear_local_APIC before trying
> to configure LVT{0/1}, which will leave LVT0 in a reset state and thus
> no write would be required in the !virt_wire_setup case?

Half of me was implying this as on option from the earlier reply.
The other half was thinking that this would be quite a lot of
behavioral change in one step. But since you think so too, why
don't we give this a try?

Jan

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

Re: [Xen-devel] [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

[Durrant, Paul]

> -Original Message-
> From: Jan Beulich 
> Sent: 23 January 2020 15:32
> To: Durrant, Paul 
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George Dunlap ; Ian
> Jackson ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Jun Nakajima ; Kevin
> Tian 
> Subject: Re: [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for
> APIC_DEFAULT_PHYS_BASE
> 
> On 23.01.2020 15:03, Paul Durrant wrote:
> > vmx_alloc_vlapic_mapping() currently contains some very odd looking code
> > that allocates a MEMF_no_owner domheap page and then shares with the
> guest
> > as if it were a xenheap page. This then requires
> vmx_free_vlapic_mapping()
> > to call a special function in the mm code: free_shared_domheap_page().
> >
> > By using a 'normal' domheap page (i.e. by not passing MEMF_no_owner to
> > alloc_domheap_page()), the odd looking code in
> vmx_alloc_vlapic_mapping()
> > can simply use get_page_and_type() to set up a writable mapping before
> > insertion in the P2M and vmx_free_vlapic_mapping() can simply release
> the
> > page using put_page_alloc_ref() followed by put_page_and_type(). This
> > then allows free_shared_domheap_page() to be purged.
> >
> > There is, however, some fall-out from this simplification:
> >
> > - alloc_domheap_page() will now call assign_pages() and run into the
> fact
> >   that 'max_pages' is not set until some time after domain_create(). To
> >   avoid an allocation failure, domain_create() is modified to set
> >   max_pages to an initial value, sufficient to cover any domheap
> >   allocations required to complete domain creation. The value will be
> >   set to the 'real' max_pages when the tool-stack later performs the
> >   XEN_DOMCTL_max_mem operation, thus allowing the rest of the domain's
> >   memory to be allocated.
> 
> I continue to disagree with this approach, and I don't think I've
> heard back on the alternative suggestion of using MEMF_no_refcount
> instead of MEMF_no_owner.

I responded in v1:

"
> Did you consider passing MEMF_no_refcount here, to avoid the
> fiddling with assign_pages()? That'll in particular also
> avoid ...
> 

You remember what happened last time we did that (with the ioreq server page), 
right? That's why assign_pages() vetoes non-refcounted pages.
"

> As said before, the page (and any other
> ones up to DOMAIN_INIT_PAGES, which I find rather fragile to be
> set to 1) will now get accounted against the amount allowed for
> the domain to allocate.
> 
> It also looks to me as if this will break e.g.
> p2m_pod_set_mem_target(), which at the very top has
> 
> /* P == B: Nothing to do (unless the guest is being created). */
> populated = d->tot_pages - p2m->pod.count;
> if ( populated > 0 && p2m->pod.entry_count == 0 )
> goto out;
> 
> This code assumes that during domain creation all pages recorded
> in ->tot_pages have also been recorded in ->pod.count.
> 
> There may be other uses of ->tot_pages which this change conflicts
> with.
> 
> > - Because the domheap page is no longer a pseudo-xenheap page, the
> >   reference counting will prevent the domain from being destroyed. Thus
> >   the call to vmx_free_vlapic_mapping() is moved from the
> >   domain_destroy() method into the domain_relinquish_resources() method.
> >   Whilst in the area, make the domain_destroy() method an optional
> >   alternative_vcall() (since it will no longer peform any function in
> VMX
> >   and is stubbed in SVM anyway).
> 
> All of this would, afaict, become irrelevant when using MEMF_no_refcount.
> 
> There looks to be one issue (which I think we have been discussing
> before): By not bumping ->tot_pages, its decrementing upon freeing
> the page will be a problem.

Yes, that's exactly the problem with assigning MEMF_no_refcount pages, which is 
way it is outlawed.

> I can see two possible solutions to this:
> - Introduce a flag indicating there should also be no accounting
>   upon freeing of the page.

What sort of flag did you have in mind? Do we have space anywhere in type-info 
or count-info to put it? If we can make assigning non-refcounted pages safe 
then it's certainly an attractive option.

> - Instead of avoiding to increment ->tot_pages, _also_ increment
>   ->max_pages. The interaction with XEN_DOMCTL_max_mem will then of
>   course be, well, interesting.
> 

Indeed, which is why I opted for the simple approach. As I've said in other 
responses, max_pages ought be set by the toolstack when the domain is created 
so I wanted to come up with something that's not too invasive until that change 
is made so if the pages do need to be ref-counted then I guess I'll have to 
figure out how to make the initial allocation co-exist with PoD.

  Paul 

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

Re: [Xen-devel] [PATCH v5 05/18] x86/mem_sharing: drop flags from mem_sharing_unshare_page

[George Dunlap]

On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> All callers pass 0 in.
> 
> Signed-off-by: Tamas K Lengyel 
> Reviewed-by: Wei Liu 

Acked-by: George Dunlap 

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

Re: [Xen-devel] [PATCH v4 7/7] x86/hyperv: setup VP assist page

[Jan Beulich]

On 22.01.2020 21:23, Wei Liu wrote:
> @@ -142,15 +143,40 @@ static void setup_hypercall_pcpu_arg(void)
>  this_cpu(hv_vp_index) = vp_index_msr;
>  }
>  
> +static void setup_vp_assist(void)
> +{
> +void *mapping;
> +uint64_t val;
> +
> +mapping = this_cpu(hv_vp_assist);
> +
> +if ( !mapping )
> +{
> +mapping = alloc_xenheap_page();
> +if ( !mapping )
> +panic("Failed to allocate vp_assist page for CPU%u\n",
> +  smp_processor_id());

Quite obviously the same AP/BSP related remark here as was given for
patch 5.

Jan

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

Re: [Xen-devel] [PATCH v5 04/18] x86/mem_sharing: make get_two_gfns take locks conditionally

[George Dunlap]

On 1/21/20 5:49 PM, Tamas K Lengyel wrote:
> During VM forking the client lock will already be taken.
> 
> Signed-off-by: Tamas K Lengyel 
> Acked-by: Andrew Coopers 

Acked-by: George Dunlap 

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

Re: [Xen-devel] [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

[George Dunlap]

On 1/23/20 3:46 PM, Durrant, Paul wrote:
>> -Original Message-
>> From: Julien Grall 
>> Sent: 23 January 2020 15:26
>> To: Durrant, Paul ; xen-devel@lists.xenproject.org
>> Cc: Jan Beulich ; Andrew Cooper
>> ; Wei Liu ; Roger Pau Monné
>> ; George Dunlap ; Ian
>> Jackson ; Konrad Rzeszutek Wilk
>> ; Stefano Stabellini ; Jun
>> Nakajima ; Kevin Tian 
>> Subject: Re: [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for
>> APIC_DEFAULT_PHYS_BASE
>>
>>
>>
>> On 23/01/2020 14:03, Paul Durrant wrote:
>>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>>> index ee3f9ffd3e..30c777acb8 100644
>>> --- a/xen/common/domain.c
>>> +++ b/xen/common/domain.c
>>> @@ -339,6 +339,8 @@ static int sanitise_domain_config(struct
>> xen_domctl_createdomain *config)
>>>   return arch_sanitise_domain_config(config);
>>>   }
>>>
>>> +#define DOMAIN_INIT_PAGES 1
>>
>> Would it make sense to make this a per-arch define? This would allow
>> each arch to define a different number of init pages (and catch any
>> misuse).
>>
> 
> I thought about that and decided against it. The arch code may want to 
> increase (which may be a bad idea) but I think it should be set early. 
> Ultimately it should come in from the toolstack via the domctl anyway.

I understood Julien to be saying that maybe Arm might want this to be
hard-coded to 5 (or 0) rather than 1.

 -George

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

Re: [Xen-devel] [PATCH v4 6/7] x86/hyperv: retrieve vp_index from Hyper-V

[Jan Beulich]

On 22.01.2020 21:23, Wei Liu wrote:
> This will be useful when invoking hypercall that targets specific
> vcpu(s).
> 
> Signed-off-by: Wei Liu 
> Reviewed-by: Paul Durrant 

For formal reasons
Acked-by: Jan Beulich 

However I wonder whether the Viridian entry in MAINTAINERS shouldn't
be extended by

F:  xen/arch/x86/guest/hyperv/

(and possibly have its title adjusted). Thoughts?

Jan

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

Re: [Xen-devel] [PATCH v5 03/18] x86/p2m: Allow p2m_get_page_from_gfn to return shared entries

[Tamas K Lengyel]

On Thu, Jan 23, 2020 at 8:32 AM George Dunlap  wrote:
>
> On 1/22/20 4:55 PM, Jan Beulich wrote:
> > On 22.01.2020 17:51, Tamas K Lengyel wrote:
> >> On Wed, Jan 22, 2020 at 8:23 AM Jan Beulich  wrote:
> >>>
> >>> On 21.01.2020 18:49, Tamas K Lengyel wrote:
>  The owner domain of shared pages is dom_cow, use that for get_page
>  otherwise the function fails to return the correct page.
> >>>
> >>> I think this description needs improvement: The function does the
> >>> special shared page dance in one place (on the "fast path")
> >>> already. This wants mentioning, either because it was a mistake
> >>> to have it just there, or because a new need has appeared to also
> >>> have it on the "slow path".
> >>
> >> It was a pre-existing error not to get the page from dom_cow for a
> >> shared entry in the slow path. I only ran into it now because the
> >> erroneous type_count check move in the previous version of the series
> >> was resulting in all pages being fully deduplicated instead of mostly
> >> being shared. Now that the pages are properly shared running LibVMI on
> >> the fork resulted in failures do to this bug.
> >>
>  --- a/xen/arch/x86/mm/p2m.c
>  +++ b/xen/arch/x86/mm/p2m.c
>  @@ -594,7 +594,10 @@ struct page_info *p2m_get_page_from_gfn(
>   if ( p2m_is_ram(*t) && mfn_valid(mfn) )
>   {
>   page = mfn_to_page(mfn);
>  -if ( !get_page(page, p2m->domain) )
>  +if ( !get_page(page, p2m->domain) &&
>  + /* Page could be shared */
>  + (!dom_cow || !p2m_is_shared(*t) ||
>  +  !get_page(page, dom_cow)) )
> >>>
> >>> While there may be a reason why on the fast path two get_page()
> >>> invocations are be necessary, couldn't you get away with just
> >>> one
> >>>
> >>> if ( !get_page(page, !dom_cow || !p2m_is_shared(*t) ? p2m->domain
> >>> : dom_cow) )
> >>>
> >>> at least here? It's also not really clear to me why here and
> >>> there we need "!dom_cow || !p2m_is_shared(*t)" - wouldn't
> >>> p2m_is_shared() return consistently "false" when !dom_cow ?
> >>
> >> I simply copied the existing code from the slow_path as-is. IMHO it
> >> would suffice to do a single get_page(page, !p2m_is_shared(*t) ?
> >> p2m->domain : dom_cow);  since we can't have any entries that are
> >> shared when dom_cow is NULL so this is safe, no need for the extra
> >> !dom_cow check. If you prefer I can make the change for both
> >> locations.
> >
> > If the change is correct to make also in the other place, I'd
> > definitely prefer you doing so.
>
> I agree with everything Jan said. :-)
>
> Also, since this is a general bugfix, you might consider moving it to
> the top of your series, so it can be checked in as soon as it's ready.

Sure - although it can be checked in before patch 1 & 2, it's not
dependent on them. In fact, all the patches in this series up to and
including Patch 14 could be checked in out-of-order.

Tamas

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

Re: [Xen-devel] [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

[Julien Grall]

On 23/01/2020 15:46, Durrant, Paul wrote:

-Original Message-
From: Julien Grall 
Sent: 23 January 2020 15:26
To: Durrant, Paul ; xen-devel@lists.xenproject.org
Cc: Jan Beulich ; Andrew Cooper
; Wei Liu ; Roger Pau Monné
; George Dunlap ; Ian
Jackson ; Konrad Rzeszutek Wilk
; Stefano Stabellini ; Jun
Nakajima ; Kevin Tian 
Subject: Re: [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for
APIC_DEFAULT_PHYS_BASE



On 23/01/2020 14:03, Paul Durrant wrote:

diff --git a/xen/common/domain.c b/xen/common/domain.c
index ee3f9ffd3e..30c777acb8 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -339,6 +339,8 @@ static int sanitise_domain_config(struct

xen_domctl_createdomain *config)

   return arch_sanitise_domain_config(config);
   }

+#define DOMAIN_INIT_PAGES 1


Would it make sense to make this a per-arch define? This would allow
each arch to define a different number of init pages (and catch any
misuse).



I thought about that and decided against it. The arch code may want to increase 
(which may be a bad idea) but I think it should be set early. Ultimately it 
should come in from the toolstack via the domctl anyway.
The value is already arch specific because on Arm we have 0 pages 
requires this trick yet.


While I agree, it should be set early, there is nothing to prevent this 
to be in a arch header. Am I correct?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

[Durrant, Paul]

> -Original Message-
> From: Julien Grall 
> Sent: 23 January 2020 15:26
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George Dunlap ; Ian
> Jackson ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Jun
> Nakajima ; Kevin Tian 
> Subject: Re: [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for
> APIC_DEFAULT_PHYS_BASE
> 
> 
> 
> On 23/01/2020 14:03, Paul Durrant wrote:
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index ee3f9ffd3e..30c777acb8 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -339,6 +339,8 @@ static int sanitise_domain_config(struct
> xen_domctl_createdomain *config)
> >   return arch_sanitise_domain_config(config);
> >   }
> >
> > +#define DOMAIN_INIT_PAGES 1
> 
> Would it make sense to make this a per-arch define? This would allow
> each arch to define a different number of init pages (and catch any
> misuse).
>

I thought about that and decided against it. The arch code may want to increase 
(which may be a bad idea) but I think it should be set early. Ultimately it 
should come in from the toolstack via the domctl anyway.

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

Re: [Xen-devel] [PATCH v4 5/7] x86/hyperv: provide percpu hypercall input page

[Jan Beulich]

On 22.01.2020 21:23, Wei Liu wrote:
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -27,7 +27,10 @@
>  #include 
>  #include 
>  
> +#include "private.h"
> +
>  struct ms_hyperv_info __read_mostly ms_hyperv;
> +DEFINE_PER_CPU_READ_MOSTLY(void *, hv_pcpu_input_arg);

Would it perhaps be helpful to make recognizable that this can hold
up to a page's worth of data, either by its type or by a slightly
different name?

> @@ -119,14 +122,36 @@ static void __init setup_hypercall_page(void)
>  }
>  }
>  
> +static void setup_hypercall_pcpu_arg(void)
> +{
> +void *mapping;
> +
> +if ( this_cpu(hv_pcpu_input_arg) )
> +return;
> +
> +mapping = alloc_xenheap_page();
> +if ( !mapping )
> +panic("Failed to allocate hypercall input page for CPU%u\n",
> +  smp_processor_id());

panic() is likely fine for the BSP, but I don't think any AP should
be able to bring down the system because of memory shortage. Such
an AP should simply not come online. (Even for the BSP the question
is whether Xen would be able to run despite failure here.)

Jan

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

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

[Roger Pau Monné]

On Fri, Jan 17, 2020 at 05:25:12PM +0100, Jan Beulich wrote:
> On 17.01.2020 17:08, Roger Pau Monné wrote:
> > On Fri, Jan 17, 2020 at 04:56:00PM +0100, Jan Beulich wrote:
> >> On 17.01.2020 16:09, 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.
> >>
> >> But there are many more instances where we (have a risk to) do so,
> >> most notably in clear_local_APIC(). The two step logic there is
> >> anyway somewhat in conflict with the citation above.
> > 
> > clear_local_APIC masks the error vector before doing any write, and
> > clears ESR afterwards, there's a comment at the top:
> > 
> > "Masking an LVT entry on a P6 can trigger a local APIC error
> > if the vector is zero. Mask LVTERR first to prevent this."
> > 
> > We could do the same (ie: mask LVTERR first and clear ESR afterwards)
> > if that seems preferable. There's a maxlvt check in clear_local_APIC,
> > but the sdm doesn't specify anyway to check if the lapic will accept a
> > masked vector 0 write or not, so not sure whether we should replicate
> > that check or just do it unconditionally on both disconnect_bsp_APIC
> > and clear_local_APIC.
> 
> I think doing it the most careful way is going to be best. I find it
> surprising anyway that disconnect_bsp_APIC() doesn't write LVTERR
> (or other LVTs except for LVT1) at all. The function looks to have a
> goal of putting the APIC back into the state that we found it when
> booting.

Maybe it would be better to just call clear_local_APIC before trying
to configure LVT{0/1}, which will leave LVT0 in a reset state and thus
no write would be required in the !virt_wire_setup case?

Roger.

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

Re: [Xen-devel] [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

[George Dunlap]

On 1/23/20 3:32 PM, Jan Beulich wrote:
> On 23.01.2020 15:03, Paul Durrant wrote:
>> vmx_alloc_vlapic_mapping() currently contains some very odd looking code
>> that allocates a MEMF_no_owner domheap page and then shares with the guest
>> as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
>> to call a special function in the mm code: free_shared_domheap_page().
>>
>> By using a 'normal' domheap page (i.e. by not passing MEMF_no_owner to
>> alloc_domheap_page()), the odd looking code in vmx_alloc_vlapic_mapping()
>> can simply use get_page_and_type() to set up a writable mapping before
>> insertion in the P2M and vmx_free_vlapic_mapping() can simply release the
>> page using put_page_alloc_ref() followed by put_page_and_type(). This
>> then allows free_shared_domheap_page() to be purged.
>>
>> There is, however, some fall-out from this simplification:
>>
>> - alloc_domheap_page() will now call assign_pages() and run into the fact
>>   that 'max_pages' is not set until some time after domain_create(). To
>>   avoid an allocation failure, domain_create() is modified to set
>>   max_pages to an initial value, sufficient to cover any domheap
>>   allocations required to complete domain creation. The value will be
>>   set to the 'real' max_pages when the tool-stack later performs the
>>   XEN_DOMCTL_max_mem operation, thus allowing the rest of the domain's
>>   memory to be allocated.
> 
> I continue to disagree with this approach, and I don't think I've
> heard back on the alternative suggestion of using MEMF_no_refcount
> instead of MEMF_no_owner. As said before, the page (and any other
> ones up to DOMAIN_INIT_PAGES, which I find rather fragile to be
> set to 1) will now get accounted against the amount allowed for
> the domain to allocate.
> 
> It also looks to me as if this will break e.g.
> p2m_pod_set_mem_target(), which at the very top has
> 
> /* P == B: Nothing to do (unless the guest is being created). */
> populated = d->tot_pages - p2m->pod.count;
> if ( populated > 0 && p2m->pod.entry_count == 0 )
> goto out;
> 
> This code assumes that during domain creation all pages recorded
> in ->tot_pages have also been recorded in ->pod.count.
> 
> There may be other uses of ->tot_pages which this change conflicts
> with.

This basically boils down to the "memory accounting swamp", where
various random features need to allocate domain pages to function.

>> - Because the domheap page is no longer a pseudo-xenheap page, the
>>   reference counting will prevent the domain from being destroyed. Thus
>>   the call to vmx_free_vlapic_mapping() is moved from the
>>   domain_destroy() method into the domain_relinquish_resources() method.
>>   Whilst in the area, make the domain_destroy() method an optional
>>   alternative_vcall() (since it will no longer peform any function in VMX
>>   and is stubbed in SVM anyway).
> 
> All of this would, afaict, become irrelevant when using MEMF_no_refcount.
> 
> There looks to be one issue (which I think we have been discussing
> before): By not bumping ->tot_pages, its decrementing upon freeing
> the page will be a problem. I can see two possible solutions to this:
> - Introduce a flag indicating there should also be no accounting
>   upon freeing of the page.

This seems like a reasonable approach to look into.

 -George

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

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

[Anthony PERARD]

On Tue, Jan 21, 2020 at 10:21:09AM +, Roger Pau Monné wrote:
> The issue is that this change is passing the guest domain_create_state
> to libxl__domain_build in libxl__spawn_stub_dm, and hence the
> stubdomain doesn't get created. I have the following patch that fixes
> it, but it's kind of dirty.
> 
> ---8<---
> From 688fde95992d07bb1123d324a68006dd08bc6512 Mon Sep 17 00:00:00 2001
> From: Roger Pau Monne 
> Date: Tue, 21 Jan 2020 10:14:09 +
> Subject: [PATCH] libxl: fix stubdomain creation after aacc143006429de
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8

:-(, this is a lie. The email I've received has a different charset. git
complained about it. Maybe next time the patch could be attached, or it
could be a proper patch with some note (after ---) (git send-email can
do --in-reply-to), or it could be two separated emails with the first
one replying to the report and the second the patch (all in the same
thread).

> Content-Transfer-Encoding: 8bit
> 
> aacc143006429de broke stubdomain creation by passing the guest
> domain_create_state to libxl__domain_build in libxl__spawn_stub_dm,
> when it should instead be crafting a new domain_create_state for the
> stubdomain.
> 
> Fixes: aacc143006429de ('tools/libxl: Plumb domain_create_state down into 
> libxl__build_pre()')
> Signed-off-by: Roger Pau Monné 
> ---
>  tools/libxl/libxl_dm.c   | 22 +-
>  tools/libxl/libxl_internal.h |  3 +--
>  2 files changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 3f08ccad1b..b1ddde77e8 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -2110,17 +2110,21 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
> libxl__domain_create_state *dcs)
>  xs_transaction_t t;
>  
>  /* convenience aliases */
> -libxl_domain_config *const dm_config = >dm_config;
>  libxl_domain_config *const guest_config = sdss->dm.guest_config;
>  const int guest_domid = sdss->dm.guest_domid;
>  libxl__domain_build_state *const d_state = sdss->dm.build_state;
> -libxl__domain_build_state *const stubdom_state = >dm_state;
> +libxl__domain_build_state *stubdom_state;
> +libxl_domain_config *dm_config;
>  
>  /* Initialise private part of sdss */
> -libxl__domain_build_state_init(stubdom_state);
>  dmss_init(>dm);
>  dmss_init(>pvqemu);
>  libxl__xswait_init(>xswait);
> +GCNEW(sdss->dcs);
> +stubdom_state = >dcs->build_state;
> +libxl__domain_build_state_init(stubdom_state);
> +GCNEW(sdss->dcs->guest_config);
> +dm_config = sdss->dcs->guest_config;

I don't think that's enough, we need to initialize the dcs properly.
Otherwise, libxl__domain_build() might start using thing that aren't set
properly. Maybe we would need a new struct which could be pass to
libxl__domain_build*, or that might be more complicated than needed.

>  
>  if (guest_config->b_info.device_model_version !=
>  LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index d919f91882..abf88dfd76 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -4102,8 +4102,7 @@ typedef struct {
>  /* filled in by user, must remain valid: */
>  libxl__dm_spawn_cb *callback; /* called as callback(,>dm,) */
>  /* private to libxl__spawn_stub_dm: */
> -libxl_domain_config dm_config;
> -libxl__domain_build_state dm_state;
> +libxl__domain_create_state *dcs;

This should be named dm_dcs, I think, to follow the same pattern as
before.


Thanks for tracking this down.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v5 03/18] x86/p2m: Allow p2m_get_page_from_gfn to return shared entries

[George Dunlap]

On 1/22/20 4:55 PM, Jan Beulich wrote:
> On 22.01.2020 17:51, Tamas K Lengyel wrote:
>> On Wed, Jan 22, 2020 at 8:23 AM Jan Beulich  wrote:
>>>
>>> On 21.01.2020 18:49, Tamas K Lengyel wrote:
 The owner domain of shared pages is dom_cow, use that for get_page
 otherwise the function fails to return the correct page.
>>>
>>> I think this description needs improvement: The function does the
>>> special shared page dance in one place (on the "fast path")
>>> already. This wants mentioning, either because it was a mistake
>>> to have it just there, or because a new need has appeared to also
>>> have it on the "slow path".
>>
>> It was a pre-existing error not to get the page from dom_cow for a
>> shared entry in the slow path. I only ran into it now because the
>> erroneous type_count check move in the previous version of the series
>> was resulting in all pages being fully deduplicated instead of mostly
>> being shared. Now that the pages are properly shared running LibVMI on
>> the fork resulted in failures do to this bug.
>>
 --- a/xen/arch/x86/mm/p2m.c
 +++ b/xen/arch/x86/mm/p2m.c
 @@ -594,7 +594,10 @@ struct page_info *p2m_get_page_from_gfn(
  if ( p2m_is_ram(*t) && mfn_valid(mfn) )
  {
  page = mfn_to_page(mfn);
 -if ( !get_page(page, p2m->domain) )
 +if ( !get_page(page, p2m->domain) &&
 + /* Page could be shared */
 + (!dom_cow || !p2m_is_shared(*t) ||
 +  !get_page(page, dom_cow)) )
>>>
>>> While there may be a reason why on the fast path two get_page()
>>> invocations are be necessary, couldn't you get away with just
>>> one
>>>
>>> if ( !get_page(page, !dom_cow || !p2m_is_shared(*t) ? p2m->domain
>>> : dom_cow) )
>>>
>>> at least here? It's also not really clear to me why here and
>>> there we need "!dom_cow || !p2m_is_shared(*t)" - wouldn't
>>> p2m_is_shared() return consistently "false" when !dom_cow ?
>>
>> I simply copied the existing code from the slow_path as-is. IMHO it
>> would suffice to do a single get_page(page, !p2m_is_shared(*t) ?
>> p2m->domain : dom_cow);  since we can't have any entries that are
>> shared when dom_cow is NULL so this is safe, no need for the extra
>> !dom_cow check. If you prefer I can make the change for both
>> locations.
> 
> If the change is correct to make also in the other place, I'd
> definitely prefer you doing so.

I agree with everything Jan said. :-)

Also, since this is a general bugfix, you might consider moving it to
the top of your series, so it can be checked in as soon as it's ready.

 -George

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

Re: [Xen-devel] [PATCH v3 1/3] x86 / vmx: make apic_access_mfn type-safe

[Andrew Cooper]

On 23/01/2020 14:03, Paul Durrant wrote:
> Use mfn_t rather than unsigned long and change previous tests against 0 to
> tests against INVALID_MFN (also introducing initialization to that value).
>
> Signed-off-by: Paul Durrant 
> Acked-by: Kevin Tian 
> Reviewed-by: Jan Beulich 
> ---
> Cc: Andrew Cooper 
> Cc: Wei Liu 
> Cc: "Roger Pau Monné" 
> Cc: Jun Nakajima 
>
> v3:
>  - Use _mfn(0) instead of INVALID_MFN

Thanks.

For the create/destroy paths to function safely, it is necessary that:

struct domain d = {};

destroy_domain();

works correctly, because it will be used to clean up from any arbitrary
early exit from create_domain() which managed to allocate a domain
struct in the first place.

This places a restriction that a bitpattern of 0 is the only detail
which can be relied upon, in the worst corner cases.

~Andrew

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

Re: [Xen-devel] [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

[Jan Beulich]

On 23.01.2020 15:03, Paul Durrant wrote:
> vmx_alloc_vlapic_mapping() currently contains some very odd looking code
> that allocates a MEMF_no_owner domheap page and then shares with the guest
> as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
> to call a special function in the mm code: free_shared_domheap_page().
> 
> By using a 'normal' domheap page (i.e. by not passing MEMF_no_owner to
> alloc_domheap_page()), the odd looking code in vmx_alloc_vlapic_mapping()
> can simply use get_page_and_type() to set up a writable mapping before
> insertion in the P2M and vmx_free_vlapic_mapping() can simply release the
> page using put_page_alloc_ref() followed by put_page_and_type(). This
> then allows free_shared_domheap_page() to be purged.
> 
> There is, however, some fall-out from this simplification:
> 
> - alloc_domheap_page() will now call assign_pages() and run into the fact
>   that 'max_pages' is not set until some time after domain_create(). To
>   avoid an allocation failure, domain_create() is modified to set
>   max_pages to an initial value, sufficient to cover any domheap
>   allocations required to complete domain creation. The value will be
>   set to the 'real' max_pages when the tool-stack later performs the
>   XEN_DOMCTL_max_mem operation, thus allowing the rest of the domain's
>   memory to be allocated.

I continue to disagree with this approach, and I don't think I've
heard back on the alternative suggestion of using MEMF_no_refcount
instead of MEMF_no_owner. As said before, the page (and any other
ones up to DOMAIN_INIT_PAGES, which I find rather fragile to be
set to 1) will now get accounted against the amount allowed for
the domain to allocate.

It also looks to me as if this will break e.g.
p2m_pod_set_mem_target(), which at the very top has

/* P == B: Nothing to do (unless the guest is being created). */
populated = d->tot_pages - p2m->pod.count;
if ( populated > 0 && p2m->pod.entry_count == 0 )
goto out;

This code assumes that during domain creation all pages recorded
in ->tot_pages have also been recorded in ->pod.count.

There may be other uses of ->tot_pages which this change conflicts
with.

> - Because the domheap page is no longer a pseudo-xenheap page, the
>   reference counting will prevent the domain from being destroyed. Thus
>   the call to vmx_free_vlapic_mapping() is moved from the
>   domain_destroy() method into the domain_relinquish_resources() method.
>   Whilst in the area, make the domain_destroy() method an optional
>   alternative_vcall() (since it will no longer peform any function in VMX
>   and is stubbed in SVM anyway).

All of this would, afaict, become irrelevant when using MEMF_no_refcount.

There looks to be one issue (which I think we have been discussing
before): By not bumping ->tot_pages, its decrementing upon freeing
the page will be a problem. I can see two possible solutions to this:
- Introduce a flag indicating there should also be no accounting
  upon freeing of the page.
- Instead of avoiding to increment ->tot_pages, _also_ increment
  ->max_pages. The interaction with XEN_DOMCTL_max_mem will then of
  course be, well, interesting.

Jan

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

Re: [Xen-devel] [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

[Julien Grall]

On 23/01/2020 14:03, Paul Durrant wrote:

diff --git a/xen/common/domain.c b/xen/common/domain.c
index ee3f9ffd3e..30c777acb8 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -339,6 +339,8 @@ static int sanitise_domain_config(struct 
xen_domctl_createdomain *config)
  return arch_sanitise_domain_config(config);
  }
  
+#define DOMAIN_INIT_PAGES 1


Would it make sense to make this a per-arch define? This would allow 
each arch to define a different number of init pages (and catch any misuse).



+
  struct domain *domain_create(domid_t domid,
   struct xen_domctl_createdomain *config,
   bool is_priv)
@@ -441,6 +443,12 @@ struct domain *domain_create(domid_t domid,
  radix_tree_init(>pirq_tree);
  }
  
+/*

+ * Allow a limited number of special pages to be allocated for the
+ * domain
+ */
+d->max_pages = DOMAIN_INIT_PAGES;
+
  if ( (err = arch_domain_create(d, config)) != 0 )
  goto fail;
  init_status |= INIT_arch;
diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h
index 2ca8882ad0..e429f38228 100644
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -317,8 +317,6 @@ struct page_info
  
  #define maddr_get_owner(ma)   (page_get_owner(maddr_to_page((ma
  
-extern void free_shared_domheap_page(struct page_info *page);

-
  #define frame_table ((struct page_info *)FRAMETABLE_VIRT_START)
  extern unsigned long max_page;
  extern unsigned long total_pages;



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 2/7] x86/hyperv: setup hypercall page

[Michael Kelley]

From: Jan Beulich  Sent: Thursday, January 23, 2020 3:19 AM
> 
> On 22.01.2020 21:23, Wei Liu wrote:
> > --- a/xen/arch/x86/e820.c
> > +++ b/xen/arch/x86/e820.c
> > @@ -36,6 +36,22 @@ boolean_param("e820-verbose", e820_verbose);
> >  struct e820map e820;
> >  struct e820map __initdata e820_raw;
> >
> > +static unsigned int find_phys_addr_bits(void)
> > +{
> > +uint32_t eax;
> > +unsigned int phys_bits = 36;
> > +
> > +eax = cpuid_eax(0x8000);
> > +if ( (eax >> 16) == 0x8000 && eax >= 0x8008 )
> > +{
> > +phys_bits = (uint8_t)cpuid_eax(0x8008);
> > +if ( phys_bits > PADDR_BITS )
> > +phys_bits = PADDR_BITS;
> > +}
> > +
> > +return phys_bits;
> > +}
> 
> Instead of this, how about pulling further ahead the call to
> early_cpu_init() in setup.c? (Otherwise the function wants to
> be __init at least.)
> 
> > @@ -357,6 +373,21 @@ static unsigned long __init find_max_pfn(void)
> >  max_pfn = end;
> >  }
> >
> > +#ifdef CONFIG_HYPERV_GUEST
> > +{
> > +   /*
> > +* We reserve the top-most page for hypercall page. Adjust
> > +* max_pfn if necessary.
> > +*/
> > +unsigned int phys_bits = find_phys_addr_bits();
> > +unsigned long hcall_pfn =
> > +  ((1ull << phys_bits) - 1) >> PAGE_SHIFT;
> > +
> > +if ( max_pfn >= hcall_pfn )
> > +  max_pfn = hcall_pfn - 1;
> > +}
> > +#endif
> 
> This wants abstracting away: There shouldn't be Hyper-V specific
> code in here if at all possible, and the adjustment also shouldn't
> be made unless actually running on Hyper-V.
> 
> > --- a/xen/arch/x86/guest/hyperv/hyperv.c
> > +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> > @@ -18,17 +18,27 @@
> >   *
> >   * Copyright (c) 2019 Microsoft.
> >   */
> > +#include 
> >  #include 
> 
> Please sort alphabetically.
> 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  struct ms_hyperv_info __read_mostly ms_hyperv;
> >
> > -static const struct hypervisor_ops ops = {
> > -.name = "Hyper-V",
> > -};
> > +static uint64_t generate_guest_id(void)
> > +{
> > +uint64_t id = 0;
> 
> Pointless initializer.
> 
> > +id = (uint64_t)HV_XEN_VENDOR_ID << 48;
> > +id |= (xen_major_version() << 16) | xen_minor_version();
> > +
> > +return id;
> > +}
> >
> > +static const struct hypervisor_ops ops;
> >  const struct hypervisor_ops *__init hyperv_probe(void)
> 
> Blank line between these two please (if you can't get away without
> this declaration in the first place).
> 
> > @@ -72,6 +82,43 @@ const struct hypervisor_ops *__init hyperv_probe(void)
> >  return 
> >  }
> >
> > +static void __init setup_hypercall_page(void)
> > +{
> > +union hv_x64_msr_hypercall_contents hypercall_msr;
> > +union hv_guest_os_id guest_id;
> > +unsigned long mfn;
> > +
> > +rdmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw);
> > +if ( !guest_id.raw )
> > +{
> > +guest_id.raw = generate_guest_id();
> > +wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id.raw);
> > +}
> > +
> > +rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> > +if ( !hypercall_msr.enable )
> > +{
> > +mfn = ((1ull << paddr_bits) - 1) >> HV_HYP_PAGE_SHIFT;
> 
> Along the lines of the abstracting-away request above: How is
> anyone to notice what else needs changing if it is decided
> that this page gets moved elsewhere?
> 
> > +hypercall_msr.enable = 1;
> > +hypercall_msr.guest_physical_address = mfn;
> > +wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> 
> So on Hyper-V the hypervisor magically populates this page as
> a side effect of the MSR write?
> 

Yes, that's exactly what happens. :-)  Hyper-V takes the guest
physical address and remaps it to a different physical page that
Hyper-V has set up with whatever is needed to execute the hypercall
sequence. The original physical page corresponding to the guest physical
address is not modified, but it remains unused and inaccessible to the
guest.  When/if the MSR is written again with the enable flag set to 0,
the mapping is flipped back, and the original physical page, with its
original contents, reappears. There are a few other pages with this
same behavior.  The Hyper-V TLFS refers to these "GPA Overlay
Pages".  See Section 5.2.1 of the TLFS.

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

Re: [Xen-devel] [PATCH v3 2/3] x86 / hvm: add domain_relinquish_resources() method

[Jan Beulich]

On 23.01.2020 15:03, Paul Durrant wrote:
> There are two functions in hvm.c to deal with tear-down and a domain:
> hvm_domain_relinquish_resources() and hvm_domain_destroy(). However, only
> the latter has an associated method in 'hvm_funcs'. This patch adds
> a method for the former.
> 
> A subsequent patch will define a VMX implementation.
> 
> Signed-off-by: Paul Durrant 

Acked-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH v3 2/2] xsm: hide detailed Xen version from unprivileged guests

[Jan Beulich]

On 23.01.2020 15:52, Julien Grall wrote:
> Therefore, they will have to accept whatever string is reported by 
> HVMLoader (or Xen). As you already allow Xen to configure it, why would 
> that be a problem to change the one in Kconfig? Why do you need to fix 
> it up in hvmloader as well?

Because, as stated before, hvmloader is actually the presentation
layer from the guest firmware pov. Hence what is sensibly coming
back as "" or "" from the hypercall should not
propagate into the firmware tables the guest gets to see. Other
users of the hypercall may very well leave these strings
unfiltered, such that to consumers it's clear what has happened
(and from other context it would then typically also be clear
what exact piece of information it is which has got hidden).

Jan

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

Re: [Xen-devel] [PATCH v3 2/2] xsm: hide detailed Xen version from unprivileged guests

[George Dunlap]

On 1/23/20 2:52 PM, Julien Grall wrote:
> Hi,
> 
> On 23/01/2020 14:45, George Dunlap wrote:
>> On 1/23/20 2:42 PM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 23/01/2020 11:32, Sergey Dyasli wrote:
 On 22/01/2020 11:25, Julien Grall wrote:
>
>
> On 22/01/2020 11:19, Sergey Dyasli wrote:
>> On 22/01/2020 10:14, Julien Grall wrote:
>>>
>>>
>>> On 22/01/2020 10:01, Sergey Dyasli wrote:
 On 20/01/2020 10:01, Jan Beulich wrote:
> On 17.01.2020 17:44, Sergey Dyasli wrote:
>> v2 --> v3:
>> - Remove hvmloader filtering
>
> Why? Seeing the prior discussion, how about adding
> XENVER_denied to
> return the "denied" string, allowing components which want to
> filter
> to know exactly what to look for? And then re-add the filtering
> you
> had? (The help text of the config option should then perhaps be
> extended to make very clear that the chosen string should not
> match
> anything that could potentially be returned by any of the XENVER_
> sub-ops.)

 I had the following reasoning:

 1. Most real-world users would set CONFIG_XSM_DENIED_STRING=""
 anyway.

 2. Filtering in DMI tables is not a complete solution, since denied
 string leaks elsewhere through the hypercall (PV guests, sysfs,
 driver
 logs) as Andrew has pointed out in the previous discussion.

 On the other hand, SMBios filtering slightly improves the
 situation for
 HVM domains, so I can return it if maintainers find it worthy.
>>>
>>> While I am not a maintainer of this code, my concern is you impose
>>> the conversion from "denied" to "" to all the users (include those
>>> who wants to keep "denied").
>>
>> This is not what's happening here: the default is still ""
>> (as
>> per patch 1); but patch 2 makes XENVER_extraversion,
>> XENVER_compile_info
>> and XENVER_changeset to return "" instead of the real values
>> which causes the UI / logs issues.
>
> I was referring the SMBios filtering... I don't think doing a blank
> filtering is the right thing to do in the hvmloader for the reason
> explained above.

 Apologies for misunderstanding the context. But I disagree about
 hvmloader. Returning "denied" from xen_version hypercall to guests is
 one thing, but hvmloader and SMBios tables are parts of the hypervisor
 and putting "denied" there is simply a terrible user experience.
>>>
>>> I am not going to comment on the user experience because this is up to
>>> another bikeshedding. The question is which string will you use? Why an
>>> empty string over something different?
>>>
>>> However, if an admin has control over the "deny" string, why would he
>>> ever want to filter it in hvmloader? Why can't he just replace the one
>>> in Kconfig?
>>
>> Most admins don't compile their own version of Xen...
> 
> Those admins are also unlikely going to build there own hvmloader, right?
> 
> Therefore, they will have to accept whatever string is reported by
> HVMLoader (or Xen). As you already allow Xen to configure it, why would
> that be a problem to change the one in Kconfig? Why do you need to fix
> it up in hvmloader as well?

Right, the idea was perhaps as upstream, we should modify hvmloader to
*always* replace "" with "".  (Or potentially with a more benign
string, like "hypervisor build unknown".)

 -George

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

Re: [Xen-devel] [PATCH v3 2/2] xsm: hide detailed Xen version from unprivileged guests

[Julien Grall]

Hi,

On 23/01/2020 14:45, George Dunlap wrote:

On 1/23/20 2:42 PM, Julien Grall wrote:

Hi,

On 23/01/2020 11:32, Sergey Dyasli wrote:

On 22/01/2020 11:25, Julien Grall wrote:



On 22/01/2020 11:19, Sergey Dyasli wrote:

On 22/01/2020 10:14, Julien Grall wrote:



On 22/01/2020 10:01, Sergey Dyasli wrote:

On 20/01/2020 10:01, Jan Beulich wrote:

On 17.01.2020 17:44, Sergey Dyasli wrote:

v2 --> v3:
- Remove hvmloader filtering


Why? Seeing the prior discussion, how about adding XENVER_denied to
return the "denied" string, allowing components which want to filter
to know exactly what to look for? And then re-add the filtering you
had? (The help text of the config option should then perhaps be
extended to make very clear that the chosen string should not match
anything that could potentially be returned by any of the XENVER_
sub-ops.)


I had the following reasoning:

1. Most real-world users would set CONFIG_XSM_DENIED_STRING=""
anyway.

2. Filtering in DMI tables is not a complete solution, since denied
string leaks elsewhere through the hypercall (PV guests, sysfs,
driver
logs) as Andrew has pointed out in the previous discussion.

On the other hand, SMBios filtering slightly improves the
situation for
HVM domains, so I can return it if maintainers find it worthy.


While I am not a maintainer of this code, my concern is you impose
the conversion from "denied" to "" to all the users (include those
who wants to keep "denied").


This is not what's happening here: the default is still "" (as
per patch 1); but patch 2 makes XENVER_extraversion,
XENVER_compile_info
and XENVER_changeset to return "" instead of the real values
which causes the UI / logs issues.


I was referring the SMBios filtering... I don't think doing a blank
filtering is the right thing to do in the hvmloader for the reason
explained above.


Apologies for misunderstanding the context. But I disagree about
hvmloader. Returning "denied" from xen_version hypercall to guests is
one thing, but hvmloader and SMBios tables are parts of the hypervisor
and putting "denied" there is simply a terrible user experience.


I am not going to comment on the user experience because this is up to
another bikeshedding. The question is which string will you use? Why an
empty string over something different?

However, if an admin has control over the "deny" string, why would he
ever want to filter it in hvmloader? Why can't he just replace the one
in Kconfig?


Most admins don't compile their own version of Xen...


Those admins are also unlikely going to build there own hvmloader, right?

Therefore, they will have to accept whatever string is reported by 
HVMLoader (or Xen). As you already allow Xen to configure it, why would 
that be a problem to change the one in Kconfig? Why do you need to fix 
it up in hvmloader as well?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

[George Dunlap]

On 1/23/20 2:03 PM, Paul Durrant wrote:
> vmx_alloc_vlapic_mapping() currently contains some very odd looking code
> that allocates a MEMF_no_owner domheap page and then shares with the guest
> as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
> to call a special function in the mm code: free_shared_domheap_page().
> 
> By using a 'normal' domheap page (i.e. by not passing MEMF_no_owner to
> alloc_domheap_page()), the odd looking code in vmx_alloc_vlapic_mapping()
> can simply use get_page_and_type() to set up a writable mapping before
> insertion in the P2M and vmx_free_vlapic_mapping() can simply release the
> page using put_page_alloc_ref() followed by put_page_and_type(). This
> then allows free_shared_domheap_page() to be purged.
> 
> There is, however, some fall-out from this simplification:
> 
> - alloc_domheap_page() will now call assign_pages() and run into the fact
>   that 'max_pages' is not set until some time after domain_create(). To
>   avoid an allocation failure, domain_create() is modified to set
>   max_pages to an initial value, sufficient to cover any domheap
>   allocations required to complete domain creation. The value will be
>   set to the 'real' max_pages when the tool-stack later performs the
>   XEN_DOMCTL_max_mem operation, thus allowing the rest of the domain's
>   memory to be allocated.
> 
> - Because the domheap page is no longer a pseudo-xenheap page, the
>   reference counting will prevent the domain from being destroyed. Thus
>   the call to vmx_free_vlapic_mapping() is moved from the
>   domain_destroy() method into the domain_relinquish_resources() method.
>   Whilst in the area, make the domain_destroy() method an optional
>   alternative_vcall() (since it will no longer peform any function in VMX
>   and is stubbed in SVM anyway).
> 
> Signed-off-by: Paul Durrant 

This is an excellent change, thank you:

Reviewed-by: George Dunlap 

My only comment is that this would have been a bit easier to review
broken down into probably three patches: 1) making domain_destroy
optional, 2) moving vmx teardown to a relinquish_resources call 3) using
"normal" pages".  But I don't think it's worth a re-send just for that.

 -George

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

Re: [Xen-devel] [PATCH v3 2/2] xsm: hide detailed Xen version from unprivileged guests

[George Dunlap]

On 1/23/20 2:42 PM, Julien Grall wrote:
> Hi,
> 
> On 23/01/2020 11:32, Sergey Dyasli wrote:
>> On 22/01/2020 11:25, Julien Grall wrote:
>>>
>>>
>>> On 22/01/2020 11:19, Sergey Dyasli wrote:
 On 22/01/2020 10:14, Julien Grall wrote:
>
>
> On 22/01/2020 10:01, Sergey Dyasli wrote:
>> On 20/01/2020 10:01, Jan Beulich wrote:
>>> On 17.01.2020 17:44, Sergey Dyasli wrote:
 v2 --> v3:
 - Remove hvmloader filtering
>>>
>>> Why? Seeing the prior discussion, how about adding XENVER_denied to
>>> return the "denied" string, allowing components which want to filter
>>> to know exactly what to look for? And then re-add the filtering you
>>> had? (The help text of the config option should then perhaps be
>>> extended to make very clear that the chosen string should not match
>>> anything that could potentially be returned by any of the XENVER_
>>> sub-ops.)
>>
>> I had the following reasoning:
>>
>> 1. Most real-world users would set CONFIG_XSM_DENIED_STRING=""
>> anyway.
>>
>> 2. Filtering in DMI tables is not a complete solution, since denied
>> string leaks elsewhere through the hypercall (PV guests, sysfs,
>> driver
>> logs) as Andrew has pointed out in the previous discussion.
>>
>> On the other hand, SMBios filtering slightly improves the
>> situation for
>> HVM domains, so I can return it if maintainers find it worthy.
>
> While I am not a maintainer of this code, my concern is you impose
> the conversion from "denied" to "" to all the users (include those
> who wants to keep "denied").

 This is not what's happening here: the default is still "" (as
 per patch 1); but patch 2 makes XENVER_extraversion,
 XENVER_compile_info
 and XENVER_changeset to return "" instead of the real values
 which causes the UI / logs issues.
>>>
>>> I was referring the SMBios filtering... I don't think doing a blank
>>> filtering is the right thing to do in the hvmloader for the reason
>>> explained above.
>>
>> Apologies for misunderstanding the context. But I disagree about
>> hvmloader. Returning "denied" from xen_version hypercall to guests is
>> one thing, but hvmloader and SMBios tables are parts of the hypervisor
>> and putting "denied" there is simply a terrible user experience.
> 
> I am not going to comment on the user experience because this is up to
> another bikeshedding. The question is which string will you use? Why an
> empty string over something different?
> 
> However, if an admin has control over the "deny" string, why would he
> ever want to filter it in hvmloader? Why can't he just replace the one
> in Kconfig?

Most admins don't compile their own version of Xen...

 -George

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

Re: [Xen-devel] [PATCH v3 2/2] xsm: hide detailed Xen version from unprivileged guests

[Julien Grall]

Hi,

On 23/01/2020 11:32, Sergey Dyasli wrote:

On 22/01/2020 11:25, Julien Grall wrote:



On 22/01/2020 11:19, Sergey Dyasli wrote:

On 22/01/2020 10:14, Julien Grall wrote:



On 22/01/2020 10:01, Sergey Dyasli wrote:

On 20/01/2020 10:01, Jan Beulich wrote:

On 17.01.2020 17:44, Sergey Dyasli wrote:

v2 --> v3:
- Remove hvmloader filtering


Why? Seeing the prior discussion, how about adding XENVER_denied to
return the "denied" string, allowing components which want to filter
to know exactly what to look for? And then re-add the filtering you
had? (The help text of the config option should then perhaps be
extended to make very clear that the chosen string should not match
anything that could potentially be returned by any of the XENVER_
sub-ops.)


I had the following reasoning:

1. Most real-world users would set CONFIG_XSM_DENIED_STRING="" anyway.

2. Filtering in DMI tables is not a complete solution, since denied
string leaks elsewhere through the hypercall (PV guests, sysfs, driver
logs) as Andrew has pointed out in the previous discussion.

On the other hand, SMBios filtering slightly improves the situation for
HVM domains, so I can return it if maintainers find it worthy.


While I am not a maintainer of this code, my concern is you impose the conversion from "denied" to 
"" to all the users (include those who wants to keep "denied").


This is not what's happening here: the default is still "" (as
per patch 1); but patch 2 makes XENVER_extraversion, XENVER_compile_info
and XENVER_changeset to return "" instead of the real values
which causes the UI / logs issues.


I was referring the SMBios filtering... I don't think doing a blank filtering 
is the right thing to do in the hvmloader for the reason explained above.


Apologies for misunderstanding the context. But I disagree about
hvmloader. Returning "denied" from xen_version hypercall to guests is
one thing, but hvmloader and SMBios tables are parts of the hypervisor
and putting "denied" there is simply a terrible user experience.


I am not going to comment on the user experience because this is up to 
another bikeshedding. The question is which string will you use? Why an 
empty string over something different?


However, if an admin has control over the "deny" string, why would he 
ever want to filter it in hvmloader? Why can't he just replace the one 
in Kconfig?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 2/2] xsm: hide detailed Xen version from unprivileged guests

[George Dunlap]

On 1/22/20 11:44 AM, Sergey Dyasli wrote:
> On 22/01/2020 10:57, George Dunlap wrote:
>> On 1/22/20 10:14 AM, Julien Grall wrote:
>>>
>>>
>>> On 22/01/2020 10:01, Sergey Dyasli wrote:
 On 20/01/2020 10:01, Jan Beulich wrote:
> On 17.01.2020 17:44, Sergey Dyasli wrote:
>> v2 --> v3:
>> - Remove hvmloader filtering
>
> Why? Seeing the prior discussion, how about adding XENVER_denied to
> return the "denied" string, allowing components which want to filter
> to know exactly what to look for? And then re-add the filtering you
> had? (The help text of the config option should then perhaps be
> extended to make very clear that the chosen string should not match
> anything that could potentially be returned by any of the XENVER_
> sub-ops.)

 I had the following reasoning:

 1. Most real-world users would set CONFIG_XSM_DENIED_STRING="" anyway.

 2. Filtering in DMI tables is not a complete solution, since denied
 string leaks elsewhere through the hypercall (PV guests, sysfs, driver
 logs) as Andrew has pointed out in the previous discussion.

 On the other hand, SMBios filtering slightly improves the situation for
 HVM domains, so I can return it if maintainers find it worthy.
>>>
>>> While I am not a maintainer of this code, my concern is you impose the
>>> conversion from "denied" to "" to all the users (include those who wants
>>> to keep "denied").
>>>
>>> If you were doing any filtering in hvmloader, then it would be best if
>>> this is configurable. But this is a bit pointless if you already allow
>>> the user to configure the string at the hypervisor level :).
>>
>> So there are two things we're concerned about:
>> - Some people don't want to scare users with a "" string
>> - Some people don't want to "silently fail" with a "" string
>>
>> The fact is, in *both cases*, this is a UI problem.  EVERY caller of
>> this interface should figure out independently what a graceful way of
>> handling failure is for their target UI.  Any caller who does not think
>> carefully about what to do in the failure case is buggy -- which
>> includes every single caller today.  The CONFIG_XSM_DENIED_STRING is a
>> gross hack fallback for buggy UIs.
>>
>> Now, I don't like to tell other people to do work, and I certainly don't
>> plan on fixing hvmloader at the moment, because it's low-priority for
>> me.  But I do think that having hvmloader detect failure and explicitly
>> make a sensible decision is the right thing to do, regardless of the
>> availability of CONFIG_XSM_DENIED_STRING to work around buggy callers.
> 
> It's not entirely clear to me what you suggest to do with hvmloader.
> Could you elaborate a bit?

Well, basically "think carefully about the user experience and decide
what to do".  Given your comment in response to Julien, I would think
that would mean checking for CONFIG_XSM_DENIED_STRING in hvmloader and
replacing it with nothing (or some other indication that's more
user-friendly).  Perhaps re-submitting your hvmloader patch as a
follow-up patch.

But as I said, it's just a suggestion.

 -George

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

Re: [Xen-devel] [PATCH V8 4/4] x86/mm: Make use of the default access param from xc_altp2m_create_view

[George Dunlap]

On 1/17/20 1:31 PM, Alexandru Stefan ISAILA wrote:
> At this moment the default_access param from xc_altp2m_create_view is
> not used.
> 
> This patch assigns default_access to p2m->default_access at the time of
> initializing a new altp2m view.
> 
> Signed-off-by: Alexandru Isaila 
> Acked-by: Jan Beulich 

Acked-by: George Dunlap 

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

[Xen-devel] [PATCH v3 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

[Paul Durrant]

vmx_alloc_vlapic_mapping() currently contains some very odd looking code
that allocates a MEMF_no_owner domheap page and then shares with the guest
as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
to call a special function in the mm code: free_shared_domheap_page().

By using a 'normal' domheap page (i.e. by not passing MEMF_no_owner to
alloc_domheap_page()), the odd looking code in vmx_alloc_vlapic_mapping()
can simply use get_page_and_type() to set up a writable mapping before
insertion in the P2M and vmx_free_vlapic_mapping() can simply release the
page using put_page_alloc_ref() followed by put_page_and_type(). This
then allows free_shared_domheap_page() to be purged.

There is, however, some fall-out from this simplification:

- alloc_domheap_page() will now call assign_pages() and run into the fact
  that 'max_pages' is not set until some time after domain_create(). To
  avoid an allocation failure, domain_create() is modified to set
  max_pages to an initial value, sufficient to cover any domheap
  allocations required to complete domain creation. The value will be
  set to the 'real' max_pages when the tool-stack later performs the
  XEN_DOMCTL_max_mem operation, thus allowing the rest of the domain's
  memory to be allocated.

- Because the domheap page is no longer a pseudo-xenheap page, the
  reference counting will prevent the domain from being destroyed. Thus
  the call to vmx_free_vlapic_mapping() is moved from the
  domain_destroy() method into the domain_relinquish_resources() method.
  Whilst in the area, make the domain_destroy() method an optional
  alternative_vcall() (since it will no longer peform any function in VMX
  and is stubbed in SVM anyway).

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Jun Nakajima 
Cc: Kevin Tian 

v2:
 - Set an initial value for max_pages rather than avoiding the check in
   assign_pages()
 - Make domain_destroy() optional
---
 xen/arch/x86/hvm/hvm.c |  4 +++-
 xen/arch/x86/hvm/svm/svm.c |  5 -
 xen/arch/x86/hvm/vmx/vmx.c | 25 -
 xen/arch/x86/mm.c  | 10 --
 xen/common/domain.c|  8 
 xen/include/asm-x86/mm.h   |  2 --
 6 files changed, 31 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e51c077269..d2610f5f01 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -746,7 +746,9 @@ void hvm_domain_destroy(struct domain *d)
 
 hvm_destroy_cacheattr_region_list(d);
 
-hvm_funcs.domain_destroy(d);
+if ( hvm_funcs.domain_destroy )
+alternative_vcall(hvm_funcs.domain_destroy, d);
+
 rtc_deinit(d);
 stdvga_deinit(d);
 vioapic_deinit(d);
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b1c376d455..b7f67f9f03 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1155,10 +1155,6 @@ static int svm_domain_initialise(struct domain *d)
 return 0;
 }
 
-static void svm_domain_destroy(struct domain *d)
-{
-}
-
 static int svm_vcpu_initialise(struct vcpu *v)
 {
 int rc;
@@ -2425,7 +2421,6 @@ static struct hvm_function_table __initdata 
svm_function_table = {
 .cpu_up   = svm_cpu_up,
 .cpu_down = svm_cpu_down,
 .domain_initialise= svm_domain_initialise,
-.domain_destroy   = svm_domain_destroy,
 .vcpu_initialise  = svm_vcpu_initialise,
 .vcpu_destroy = svm_vcpu_destroy,
 .save_cpu_ctxt= svm_save_vmcb_ctxt,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b262d38a7c..c3a06b54a8 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -419,7 +419,7 @@ static int vmx_domain_initialise(struct domain *d)
 return 0;
 }
 
-static void vmx_domain_destroy(struct domain *d)
+static void vmx_domain_relinquish_resources(struct domain *d)
 {
 if ( !has_vlapic(d) )
 return;
@@ -2240,7 +2240,7 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .cpu_up_prepare   = vmx_cpu_up_prepare,
 .cpu_dead = vmx_cpu_dead,
 .domain_initialise= vmx_domain_initialise,
-.domain_destroy   = vmx_domain_destroy,
+.domain_relinquish_resources = vmx_domain_relinquish_resources,
 .vcpu_initialise  = vmx_vcpu_initialise,
 .vcpu_destroy = vmx_vcpu_destroy,
 .save_cpu_ctxt= vmx_save_vmcs_ctxt,
@@ -3028,12 +3028,22 @@ static int vmx_alloc_vlapic_mapping(struct domain *d)
 if ( !cpu_has_vmx_virtualize_apic_accesses )
 return 0;
 
-pg = alloc_domheap_page(d, MEMF_no_owner);
+pg = alloc_domheap_page(d, 0);
 if ( !pg )
 return -ENOMEM;
+
+if ( !get_page_and_type(pg, d, PGT_writable_page) )
+{
+/*
+ * The domain can't possibly 

[Xen-devel] [PATCH v3 0/3] purge free_shared_domheap_page()

[Paul Durrant]

Paul Durrant (3):
  x86 / vmx: make apic_access_mfn type-safe
  x86 / hvm: add domain_relinquish_resources() method
  x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

 xen/arch/x86/hvm/hvm.c |  7 +-
 xen/arch/x86/hvm/mtrr.c|  2 +-
 xen/arch/x86/hvm/svm/svm.c |  5 
 xen/arch/x86/hvm/vmx/vmx.c | 37 +-
 xen/arch/x86/mm.c  | 10 
 xen/common/domain.c|  8 +++
 xen/include/asm-x86/hvm/hvm.h  |  1 +
 xen/include/asm-x86/hvm/vmx/vmcs.h |  2 +-
 xen/include/asm-x86/mm.h   |  2 --
 9 files changed, 43 insertions(+), 31 deletions(-)

-- 
2.20.1


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

[Xen-devel] [PATCH v3 2/3] x86 / hvm: add domain_relinquish_resources() method

[Paul Durrant]

There are two functions in hvm.c to deal with tear-down and a domain:
hvm_domain_relinquish_resources() and hvm_domain_destroy(). However, only
the latter has an associated method in 'hvm_funcs'. This patch adds
a method for the former.

A subsequent patch will define a VMX implementation.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: Jun Nakajima 
Cc: Kevin Tian 

v2:
 - Make the new method optional and make it an alternative_vcall
---
 xen/arch/x86/hvm/hvm.c| 3 +++
 xen/include/asm-x86/hvm/hvm.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 4723f5d09c..e51c077269 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -715,6 +715,9 @@ int hvm_domain_initialise(struct domain *d)
 
 void hvm_domain_relinquish_resources(struct domain *d)
 {
+if ( hvm_funcs.domain_relinquish_resources )
+alternative_vcall(hvm_funcs.domain_relinquish_resources, d);
+
 if ( hvm_funcs.nhvm_domain_relinquish_resources )
 hvm_funcs.nhvm_domain_relinquish_resources(d);
 
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 09793c12e9..9eab1d7493 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -107,6 +107,7 @@ struct hvm_function_table {
  * Initialise/destroy HVM domain/vcpu resources
  */
 int  (*domain_initialise)(struct domain *d);
+void (*domain_relinquish_resources)(struct domain *d);
 void (*domain_destroy)(struct domain *d);
 int  (*vcpu_initialise)(struct vcpu *v);
 void (*vcpu_destroy)(struct vcpu *v);
-- 
2.20.1


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

[Xen-devel] [PATCH v3 1/3] x86 / vmx: make apic_access_mfn type-safe

[Paul Durrant]

Use mfn_t rather than unsigned long and change previous tests against 0 to
tests against INVALID_MFN (also introducing initialization to that value).

Signed-off-by: Paul Durrant 
Acked-by: Kevin Tian 
Reviewed-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: Jun Nakajima 

v3:
 - Use _mfn(0) instead of INVALID_MFN

v2:
 - Set apic_access_mfn to INVALID_MFN in vmx_free_vlapic_mapping() to make
   the function idempotent
---
 xen/arch/x86/hvm/mtrr.c|  2 +-
 xen/arch/x86/hvm/vmx/vmx.c | 14 +++---
 xen/include/asm-x86/hvm/vmx/vmcs.h |  2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 5ad15eafe0..8356e8de3d 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -818,7 +818,7 @@ int epte_get_entry_emt(struct domain *d, unsigned long gfn, 
mfn_t mfn,
 
 if ( direct_mmio )
 {
-if ( (mfn_x(mfn) ^ d->arch.hvm.vmx.apic_access_mfn) >> order )
+if ( (mfn_x(mfn) ^ mfn_x(d->arch.hvm.vmx.apic_access_mfn)) >> order )
 return MTRR_TYPE_UNCACHABLE;
 if ( order )
 return -1;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index f83f102638..b262d38a7c 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3034,7 +3034,7 @@ static int vmx_alloc_vlapic_mapping(struct domain *d)
 mfn = page_to_mfn(pg);
 clear_domain_page(mfn);
 share_xen_page_with_guest(pg, d, SHARE_rw);
-d->arch.hvm.vmx.apic_access_mfn = mfn_x(mfn);
+d->arch.hvm.vmx.apic_access_mfn = mfn;
 
 return set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE), mfn,
   PAGE_ORDER_4K,
@@ -3043,24 +3043,24 @@ static int vmx_alloc_vlapic_mapping(struct domain *d)
 
 static void vmx_free_vlapic_mapping(struct domain *d)
 {
-unsigned long mfn = d->arch.hvm.vmx.apic_access_mfn;
+mfn_t mfn = d->arch.hvm.vmx.apic_access_mfn;
 
-if ( mfn != 0 )
-free_shared_domheap_page(mfn_to_page(_mfn(mfn)));
+d->arch.hvm.vmx.apic_access_mfn = _mfn(0);
+if ( !mfn_eq(mfn, _mfn(0)) )
+free_shared_domheap_page(mfn_to_page(mfn));
 }
 
 static void vmx_install_vlapic_mapping(struct vcpu *v)
 {
 paddr_t virt_page_ma, apic_page_ma;
 
-if ( v->domain->arch.hvm.vmx.apic_access_mfn == 0 )
+if ( mfn_eq(v->domain->arch.hvm.vmx.apic_access_mfn, _mfn(0)) )
 return;
 
 ASSERT(cpu_has_vmx_virtualize_apic_accesses);
 
 virt_page_ma = page_to_maddr(vcpu_vlapic(v)->regs_page);
-apic_page_ma = v->domain->arch.hvm.vmx.apic_access_mfn;
-apic_page_ma <<= PAGE_SHIFT;
+apic_page_ma = mfn_to_maddr(v->domain->arch.hvm.vmx.apic_access_mfn);
 
 vmx_vmcs_enter(v);
 __vmwrite(VIRTUAL_APIC_PAGE_ADDR, virt_page_ma);
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index a514299144..be4661a929 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -59,7 +59,7 @@ struct ept_data {
 #define _VMX_DOMAIN_PML_ENABLED0
 #define VMX_DOMAIN_PML_ENABLED (1ul << _VMX_DOMAIN_PML_ENABLED)
 struct vmx_domain {
-unsigned long apic_access_mfn;
+mfn_t apic_access_mfn;
 /* VMX_DOMAIN_* */
 unsigned int status;
 
-- 
2.20.1


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 146058
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
fail REGR. vs. 146058

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

version targeted for testing:
 xen  021cc01ecac111be3301ad33ff5cda4543ca8b92
baseline version:
 xen  03bfe526ecadc86f31eda433b91dc90be0563919

Last test of basis   

Re: [Xen-devel] [PATCH v2 1/3] x86 / vmx: make apic_access_mfn type-safe

[Durrant, Paul]

> -Original Message-
> From: Jan Beulich 
> Sent: 23 January 2020 13:30
> To: Durrant, Paul 
> Cc: Kevin Tian ; Wei Liu ; Andrew Cooper
> ; Jun Nakajima ; xen-
> de...@lists.xenproject.org; Roger Pau Monné 
> Subject: Re: [PATCH v2 1/3] x86 / vmx: make apic_access_mfn type-safe
> 
> On 23.01.2020 14:09, Durrant, Paul wrote:
> >> -Original Message-
> >> From: Xen-devel  On Behalf Of
> Jan
> >> Beulich
> >> Sent: 23 January 2020 12:45
> >> To: Durrant, Paul 
> >> Cc: Kevin Tian ; Wei Liu ; Andrew
> Cooper
> >> ; Jun Nakajima ;
> xen-
> >> de...@lists.xenproject.org; Roger Pau Monné 
> >> Subject: Re: [Xen-devel] [PATCH v2 1/3] x86 / vmx: make apic_access_mfn
> >> type-safe
> >>
> >> On 23.01.2020 13:21, Paul Durrant wrote:
> >>> Use mfn_t rather than unsigned long and change previous tests against
> 0
> >> to
> >>> tests against INVALID_MFN (also introducing initialization to that
> >> value).
> >>>
> >>> Signed-off-by: Paul Durrant 
> >>> Acked-by: Kevin Tian 
> >>> Reviewed-by: Jan Beulich 
> >>
> >> No, this isn't what the R-b was given for.
> >
> > Oh, sorry, I misunderstood; I thought the R-b was good as long as
> idempotency was ensured.
> >
> >>
> >>> v2:
> >>>  - Set apic_access_mfn to INVALID_MFN in vmx_free_vlapic_mapping() to
> >> make
> >>>the function idempotent
> >>
> >> Andrew had suggested to use 0 instead of INVALID_MFN. I don't see
> >> how you achieved idempotency with this adjustment. Aiui
> >> vmx_free_vlapic_mapping() is supposed to also run correctly if
> >> vmx_alloc_vlapic_mapping() was never called.
> >
> > It will. vmx_domain_initialise() will set apic_access_mfn to INVALID_MFN
> > so vmx_free_vlapic_mapping() will do nothing.
> 
> I'm sorry, it was implied that it also needs to work if
> vmx_domain_initialise() was never called. Andrew's goal after
> all is, aiui, to be able to call "destroy" functions on error
> paths irrespective of how far "create" had managed to progress.
> 

Oh, I see. That implication was not at all obvious to me. I thought he was just 
after being able to 'destroy' as many times as it took to finish, in which case 
our choice for the value of INVALID_MFN is indeed unfortunate. If that's the 
goal I'll switch to use _mfn(0) as a comparator.

  Paul

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

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

[osstest service owner]

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

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-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   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
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 build-amd64-libvirt   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-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  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-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-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  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-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-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-xsm   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-libvirt-pair  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-amd64-pygrub   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64 

Re: [Xen-devel] [PATCH v2 1/3] x86 / vmx: make apic_access_mfn type-safe

[Jan Beulich]

On 23.01.2020 14:09, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel  On Behalf Of Jan
>> Beulich
>> Sent: 23 January 2020 12:45
>> To: Durrant, Paul 
>> Cc: Kevin Tian ; Wei Liu ; Andrew Cooper
>> ; Jun Nakajima ; xen-
>> de...@lists.xenproject.org; Roger Pau Monné 
>> Subject: Re: [Xen-devel] [PATCH v2 1/3] x86 / vmx: make apic_access_mfn
>> type-safe
>>
>> On 23.01.2020 13:21, Paul Durrant wrote:
>>> Use mfn_t rather than unsigned long and change previous tests against 0
>> to
>>> tests against INVALID_MFN (also introducing initialization to that
>> value).
>>>
>>> Signed-off-by: Paul Durrant 
>>> Acked-by: Kevin Tian 
>>> Reviewed-by: Jan Beulich 
>>
>> No, this isn't what the R-b was given for.
> 
> Oh, sorry, I misunderstood; I thought the R-b was good as long as idempotency 
> was ensured.
> 
>>
>>> v2:
>>>  - Set apic_access_mfn to INVALID_MFN in vmx_free_vlapic_mapping() to
>> make
>>>the function idempotent
>>
>> Andrew had suggested to use 0 instead of INVALID_MFN. I don't see
>> how you achieved idempotency with this adjustment. Aiui
>> vmx_free_vlapic_mapping() is supposed to also run correctly if
>> vmx_alloc_vlapic_mapping() was never called.
> 
> It will. vmx_domain_initialise() will set apic_access_mfn to INVALID_MFN
> so vmx_free_vlapic_mapping() will do nothing.

I'm sorry, it was implied that it also needs to work if
vmx_domain_initialise() was never called. Andrew's goal after
all is, aiui, to be able to call "destroy" functions on error
paths irrespective of how far "create" had managed to progress.

Jan

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

Re: [Xen-devel] [PATCH v2] cmdline: treat hyphens and underscores the same

[Jan Beulich]

On 23.01.2020 13:11, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel  On Behalf Of Jan
>> Beulich
>> Sent: 23 January 2020 11:43
>> To: xen-devel@lists.xenproject.org
>> Cc: Stefano Stabellini ; Julien Grall
>> ; Wei Liu ; Konrad Wilk
>> ; George Dunlap ;
>> Andrew Cooper ; Ian Jackson
>> 
>> Subject: [Xen-devel] [PATCH v2] cmdline: treat hyphens and underscores the
>> same
>>
>> In order to avoid permanently having to ask that no new command line
>> options using underscores be introduced (albeit I'm likely to still make
>> remarks), and in order to also allow extending the use of hyphens to
>> pre-existing ones, introduce custom comparison functions treating both
>> characters as matching.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> v2: Rename to opt_str{,n}cmp(). Don't use the new function for comapring
>> against "no-" in parse_params(). Add comment to cdiff().
>>
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -72,6 +72,11 @@ Some options take a comma separated list
>>  Some parameters act as combinations of the above, most commonly a mix
>>  of Boolean and String.  These are noted in the relevant sections.
>>
>> +### Spelling
>> +
>> +Parameter names may include hyphens or underscores.  These are
>> +generally being treated as matching one another by the parsing logic.
>> +
>>  ## Parameter details
>>
>>  ### acpi
>> --- a/xen/common/kernel.c
>> +++ b/xen/common/kernel.c
>> @@ -23,6 +23,53 @@ enum system_state system_state = SYS_STA
>>  xen_commandline_t saved_cmdline;
>>  static const char __initconst opt_builtin_cmdline[] = CONFIG_CMDLINE;
>>
>> +/*
>> + * Calculate the difference between two characters for command line
>> parsing
>> + * purposes, i.e. treating '-' and '_' the same.
>> + */
>> +static int cdiff(unsigned char c1, unsigned char c2)
>> +{
>> +int res = c1 - c2;
>> +
>> +if ( res && (c1 ^ c2) == ('-' ^ '_') &&
>> + (c1 == '-' || c1 == '_') )
>> +res = 0;
>> +
> 
> Wow! That makes my head hurt. How about:
> 
> static int cdiff(unsigned char c1, unsigned char c2)
> {
> if ( c1 == '-' )
> c1 = '_';
> 
> if ( c2 == '-' )
> c2 = '_';
> 
> return c1 - c2;
> }
> 
> ?

This would work for the current uses where ultimately the
result is only evaluated for being (non-)zero, but wouldn't
be correct when used for actual collation.

Jan

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

Re: [Xen-devel] [PATCH v2 1/3] x86 / vmx: make apic_access_mfn type-safe

[Durrant, Paul]

> -Original Message-
> From: Xen-devel  On Behalf Of Jan
> Beulich
> Sent: 23 January 2020 12:45
> To: Durrant, Paul 
> Cc: Kevin Tian ; Wei Liu ; Andrew Cooper
> ; Jun Nakajima ; xen-
> de...@lists.xenproject.org; Roger Pau Monné 
> Subject: Re: [Xen-devel] [PATCH v2 1/3] x86 / vmx: make apic_access_mfn
> type-safe
> 
> On 23.01.2020 13:21, Paul Durrant wrote:
> > Use mfn_t rather than unsigned long and change previous tests against 0
> to
> > tests against INVALID_MFN (also introducing initialization to that
> value).
> >
> > Signed-off-by: Paul Durrant 
> > Acked-by: Kevin Tian 
> > Reviewed-by: Jan Beulich 
> 
> No, this isn't what the R-b was given for.

Oh, sorry, I misunderstood; I thought the R-b was good as long as idempotency 
was ensured.

> 
> > v2:
> >  - Set apic_access_mfn to INVALID_MFN in vmx_free_vlapic_mapping() to
> make
> >the function idempotent
> 
> Andrew had suggested to use 0 instead of INVALID_MFN. I don't see
> how you achieved idempotency with this adjustment. Aiui
> vmx_free_vlapic_mapping() is supposed to also run correctly if
> vmx_alloc_vlapic_mapping() was never called.

It will. vmx_domain_initialise() will set apic_access_mfn to INVALID_MFN so 
vmx_free_vlapic_mapping() will do nothing.

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

Re: [Xen-devel] [PATCH v2 1/3] x86 / vmx: make apic_access_mfn type-safe

[Jan Beulich]

On 23.01.2020 13:21, Paul Durrant wrote:
> Use mfn_t rather than unsigned long and change previous tests against 0 to
> tests against INVALID_MFN (also introducing initialization to that value).
> 
> Signed-off-by: Paul Durrant 
> Acked-by: Kevin Tian 
> Reviewed-by: Jan Beulich 

No, this isn't what the R-b was given for.

> v2:
>  - Set apic_access_mfn to INVALID_MFN in vmx_free_vlapic_mapping() to make
>the function idempotent

Andrew had suggested to use 0 instead of INVALID_MFN. I don't see
how you achieved idempotency with this adjustment. Aiui
vmx_free_vlapic_mapping() is supposed to also run correctly if
vmx_alloc_vlapic_mapping() was never called.

Jan

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

Re: [Xen-devel] [PATCH V8 3/4] x86/mm: Pull vendor-independent altp2m code out of p2m-ept.c and into p2m.c

[George Dunlap]

On 1/17/20 1:31 PM, Alexandru Stefan ISAILA wrote:
> No functional changes.
> 
> Requested-by: Jan Beulich 
> Signed-off-by: Alexandru Isaila 
> Reviewed-by: Jan Beulich 

Acked-by: George Dunlap 

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

Re: [Xen-devel] [PATCH V8 2/4] x86/altp2m: Add hypercall to set a range of sve bits

[George Dunlap]

On 1/17/20 1:31 PM, Alexandru Stefan ISAILA wrote:
> By default the sve bits are not set.
> This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
> to set a range of sve bits.
> The core function, p2m_set_suppress_ve_multi(), does not break in case
> of a error and it is doing a best effort for setting the bits in the
> given range. A check for continuation is made in order to have
> preemption on large ranges.
> The gfn of the first error is stored in
> xen_hvm_altp2m_suppress_ve_multi.first_error_gfn and the error code is
> stored in xen_hvm_altp2m_suppress_ve_multi.first_error.
> If no error occurred the values will be 0.
> 
> Signed-off-by: Alexandru Isaila 

Acked-by: George Dunlap 

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

Re: [Xen-devel] [PATCH v4 1/2] xen/arm: remove physical timer offset

[Julien Grall]

Hi,

On 21/01/2020 15:07, Jeff Kubascik wrote:

The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section
D11.2.4 Timers, the "Offset" between the counter and timer should be
zero for a physical timer. This removes the offset to make the timer and
counter consistent.

This also cleans up the physical timer implementation to better match
the virtual timer - both cval's now hold the hardware value.

Signed-off-by: Jeff Kubascik 
---
  xen/arch/arm/vtimer.c| 34 ++
  xen/include/asm-arm/domain.h |  3 ---
  2 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 240a850b6e..0c78a65863 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -62,7 +62,6 @@ static void virt_timer_expired(void *data)
  
  int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig *config)

  {
-d->arch.phys_timer_base.offset = NOW();
  d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0);
  d->time_offset.seconds = ticks_to_ns(d->arch.virt_timer_base.offset - 
boot_count);
  do_div(d->time_offset.seconds, 10);
@@ -108,7 +107,6 @@ int vcpu_vtimer_init(struct vcpu *v)
  
  init_timer(>timer, phys_timer_expired, t, v->processor);

  t->ctl = 0;
-t->cval = NOW();
  t->irq = d0
  ? timer_get_irq(TIMER_PHYS_NONSECURE_PPI)
  : GUEST_TIMER_PHYS_NS_PPI;
@@ -167,6 +165,7 @@ void virt_timer_restore(struct vcpu *v)
  static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, bool 
read)
  {
  struct vcpu *v = current;
+s_time_t expires;
  
  if ( !ACCESS_ALLOWED(regs, EL0PTEN) )

  return false;
@@ -184,8 +183,9 @@ static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, 
uint32_t *r, bool read)
  
  if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )

  {
-set_timer(>arch.phys_timer.timer,
-  v->arch.phys_timer.cval + 
v->domain->arch.phys_timer_base.offset);
+expires = v->arch.phys_timer.cval > boot_count
+  ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0;
+set_timer(>arch.phys_timer.timer, expires);


While the factoring was optional, my request of a comment wasn't (even 
if it requires to duplicate 3 times).


If you suggest a comment and an update of the commit message, I can 
merge it in this patch on commit.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/2] nvmx: fix handling of interrupts

[Roger Pau Monné]

On Tue, Jan 21, 2020 at 03:34:13AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné 
> > Sent: Monday, January 20, 2020 6:19 PM
> > 
> > On Sun, Jan 19, 2020 at 04:15:04AM +, Tian, Kevin wrote:
> > > > From: Roger Pau Monne 
> > > > Sent: Wednesday, January 8, 2020 6:39 PM
> > > >
> > > > When doing a virtual vmexit (ie: a vmexit handled by the L1 VMM)
> > > > interrupts shouldn't be injected using the virtual interrupt delivery
> > > > mechanism, and instead should be signaled in the vmcs using the exit
> > > > reason and the interruption-information field if the "Acknowledge
> > > > interrupt on exit" vmexit control is set.
> > > >
> > > > Remove the nvmx_update_apicv helper: it's bogus to attempt to inject
> > > > interrupts on virtual vmexit using the virtual interrupt delivery
> > > > assistance, and it's also bogus to ack interrupts without checking if
> > > > the vmexit "Acknowledge interrupt on exit" vmexit control is set.
> > > > nvmx_intr_intercept already handles interrupts correctly on virtual
> > > > vmexit.
> > > >
> > > > Note that this fixes the usage of x2APIC by the L1 VMM, at least when
> > > > the L1 VMM is Xen.
> > >
> > > while this fix makes sense to me, can you also test other L1 VMMs,
> > > so we don't overlook some other intentions covered or hidden by
> > > removed logic?
> > 
> > I could test other hypervisors, but do we really expect anything
> > that's not Xen on Xen to work?
> > 
> > I'm asking because that's the only combination that's actually tested
> > by osstest.
> > 
> > Thanks, Roger.
> 
> If others are OK with your assumption, then it's fine. I didn't tightly 
> follow the nested virtualization requirements in Xen.
> 
> On the other hand, I think this patch needs a revision. It is not bogus
> to use virtual interrupt delivery on virtual VMexit, if "Ack interrupt
> on exit" is off. In such case, the delivery doesn't happen until L1 
> hypervisor enables interrupt to clear interrupt window. Then it does
> save one exit. The only bogus point is that nvmx_udpate_apicv doesn't
> check "Ack interrupt on exit". So I prefer to add such check there 
> instead of completely removing this optimization.

I went back over this, and I'm still not sure calling
nvmx_update_apicv is actually required: AFAICT vmx_intr_assist will
already inject the interrupt correctly using virtual interrupt
delivery if left pending on the vlapic. I guess the code in
nvmx_update_apicv doesn't hurt as long as it's gated on "Ack on exit"
not being enabled, but it's likely redundant.

I will send an updated patch anyway, since I would like to get this
sorted out sooner rather than later and will follow your advise of
leaving nvmx_update_apicv in place gated by a check of whether "Ack on
exit" is not enabled.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 2/2] xen/arm: Sign extend TimerValue when computing the CompareValue

[Julien Grall]

Hi,

On 21/01/2020 15:07, Jeff Kubascik wrote:

Xen will only store the CompareValue as it can be derived from the
TimerValue (ARM DDI 0487E.a section D11.2.4):

   CompareValue = (Counter[63:0] + SignExtend(TimerValue))[63:0]

While the TimerValue is a 32-bit signed value, our implementation
assumed it is a 32-bit unsigned value.

Signed-off-by: Jeff Kubascik 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 1/2] xen/arm: remove physical timer offset

[Julien Grall]

Hi,

On 17/01/2020 21:24, Jeff Kubascik wrote:

On 12/18/2019 9:20 AM, Julien Grall wrote:

Hi Jeff,

On 11/12/2019 21:13, Jeff Kubascik wrote:

The physical timer traps apply an offset so that time starts at 0 for
the guest. However, this offset is not currently applied to the physical
counter. Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section
D11.2.4 Timers, the "Offset" between the counter and timer should be
zero for a physical timer. This removes the offset to make the timer and
counter consistent.

This also cleans up the physical timer implementation to better match
the virtual timer - both cval's now hold the hardware value.

Signed-off-by: Jeff Kubascik 
---
   xen/arch/arm/vtimer.c| 34 ++
   xen/include/asm-arm/domain.h |  3 ---
   2 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index e6aebdac9e..21b98ec20a 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -62,7 +62,6 @@ static void virt_timer_expired(void *data)

   int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig 
*config)
   {
-d->arch.phys_timer_base.offset = NOW();
   d->arch.virt_timer_base.offset = READ_SYSREG64(CNTPCT_EL0);
   d->time_offset_seconds = ticks_to_ns(d->arch.virt_timer_base.offset - 
boot_count);
   do_div(d->time_offset_seconds, 10);
@@ -108,7 +107,6 @@ int vcpu_vtimer_init(struct vcpu *v)

   init_timer(>timer, phys_timer_expired, t, v->processor);
   t->ctl = 0;
-t->cval = NOW();
   t->irq = d0
   ? timer_get_irq(TIMER_PHYS_NONSECURE_PPI)
   : GUEST_TIMER_PHYS_NS_PPI;
@@ -167,6 +165,7 @@ void virt_timer_restore(struct vcpu *v)
   static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, bool 
read)
   {
   struct vcpu *v = current;
+s_time_t expires;

   if ( !ACCESS_ALLOWED(regs, EL0PTEN) )
   return false;
@@ -184,8 +183,9 @@ static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, 
uint32_t *r, bool read)

   if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
   {
-set_timer(>arch.phys_timer.timer,
-  v->arch.phys_timer.cval + 
v->domain->arch.phys_timer_base.offset);
+expires = v->arch.phys_timer.cval > boot_count
+  ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0;
+set_timer(>arch.phys_timer.timer, expires);
   }
   else
   stop_timer(>arch.phys_timer.timer);
@@ -197,26 +197,27 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs, 
uint32_t *r,
bool read)
   {
   struct vcpu *v = current;
-s_time_t now;
+uint64_t cntpct;
+s_time_t expires;

   if ( !ACCESS_ALLOWED(regs, EL0PTEN) )
   return false;

-now = NOW() - v->domain->arch.phys_timer_base.offset;
+cntpct = get_cycles();

   if ( read )
   {
-*r = (uint32_t)(ns_to_ticks(v->arch.phys_timer.cval - now) & 
0xull);
+*r = (uint32_t)((v->arch.phys_timer.cval - cntpct) & 0xull);
   }
   else
   {
-v->arch.phys_timer.cval = now + ticks_to_ns(*r);
+v->arch.phys_timer.cval = cntpct + *r;
   if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
   {
   v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
-set_timer(>arch.phys_timer.timer,
-  v->arch.phys_timer.cval +
-  v->domain->arch.phys_timer_base.offset);
+expires = v->arch.phys_timer.cval > boot_count
+  ? ticks_to_ns(v->arch.phys_timer.cval - boot_count) : 0;


You probably want a comment to explain why you set to 0 here.


This code is repeated in 3 places - it probably doesn't make sense to have 3
duplicate comments as well. I think it would fit well with your function
suggestion below.


If you don't write a new helper, then the comment *must* be duplicated 
on every use. It is not pretty, but at least it avoids the reader to 
wonder why this is done.


Similar, this should be explained in the commit message.




+set_timer(>arch.phys_timer.timer, expires);
   }
   }
   return true;
@@ -226,23 +227,24 @@ static bool vtimer_cntp_cval(struct cpu_user_regs *regs, 
uint64_t *r,
bool read)
   {
   struct vcpu *v = current;
+s_time_t expires;

   if ( !ACCESS_ALLOWED(regs, EL0PTEN) )
   return false;

   if ( read )
   {
-*r = ns_to_ticks(v->arch.phys_timer.cval);
+*r = v->arch.phys_timer.cval;
   }
   else
   {
-v->arch.phys_timer.cval = ticks_to_ns(*r);
+v->arch.phys_timer.cval = *r;
   if ( v->arch.phys_timer.ctl & CNTx_CTL_ENABLE )
   {
   v->arch.phys_timer.ctl &= ~CNTx_CTL_PENDING;
-set_timer(>arch.phys_timer.timer,
-  

Re: [Xen-devel] [PATCH V8 1/4] x86/mm: Add array_index_nospec to guest provided index values

[George Dunlap]

On 1/17/20 1:31 PM, Alexandru Stefan ISAILA wrote:
> This patch aims to sanitize indexes, potentially guest provided
> values, for altp2m_eptp[] and altp2m_p2m[] arrays.
> 
> Requested-by: Jan Beulich 
> Signed-off-by: Alexandru Isaila 
> Acked-by: Tamas K Lengyel 

Acked-by: George Dunlap 

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

[Xen-devel] [PATCH v2 3/3] x86 / vmx: use a 'normal' domheap page for APIC_DEFAULT_PHYS_BASE

[Paul Durrant]

vmx_alloc_vlapic_mapping() currently contains some very odd looking code
that allocates a MEMF_no_owner domheap page and then shares with the guest
as if it were a xenheap page. This then requires vmx_free_vlapic_mapping()
to call a special function in the mm code: free_shared_domheap_page().

By using a 'normal' domheap page (i.e. by not passing MEMF_no_owner to
alloc_domheap_page()), the odd looking code in vmx_alloc_vlapic_mapping()
can simply use get_page_and_type() to set up a writable mapping before
insertion in the P2M and vmx_free_vlapic_mapping() can simply release the
page using put_page_alloc_ref() followed by put_page_and_type(). This
then allows free_shared_domheap_page() to be purged.

There is, however, some fall-out from this simplification:

- alloc_domheap_page() will now call assign_pages() and run into the fact
  that 'max_pages' is not set until some time after domain_create(). To
  avoid an allocation failure, domain_create() is modified to set
  max_pages to an initial value, sufficient to cover any domheap
  allocations required to complete domain creation. The value will be
  set to the 'real' max_pages when the tool-stack later performs the
  XEN_DOMCTL_max_mem operation, thus allowing the rest of the domain's
  memory to be allocated.

- Because the domheap page is no longer a pseudo-xenheap page, the
  reference counting will prevent the domain from being destroyed. Thus
  the call to vmx_free_vlapic_mapping() is moved from the
  domain_destroy() method into the domain_relinquish_resources() method.
  Whilst in the area, make the domain_destroy() method an optional
  alternative_vcall() (since it will no longer peform any function in VMX
  and is stubbed in SVM anyway).

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Jun Nakajima 
Cc: Kevin Tian 

v2:
 - Set an initial value for max_pages rather than avoiding the check in
   assign_pages()
 - Make domain_destroy() optional
---
 xen/arch/x86/hvm/hvm.c |  4 +++-
 xen/arch/x86/hvm/svm/svm.c |  5 -
 xen/arch/x86/hvm/vmx/vmx.c | 25 -
 xen/arch/x86/mm.c  | 10 --
 xen/common/domain.c|  8 
 xen/include/asm-x86/mm.h   |  2 --
 6 files changed, 31 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e51c077269..d2610f5f01 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -746,7 +746,9 @@ void hvm_domain_destroy(struct domain *d)
 
 hvm_destroy_cacheattr_region_list(d);
 
-hvm_funcs.domain_destroy(d);
+if ( hvm_funcs.domain_destroy )
+alternative_vcall(hvm_funcs.domain_destroy, d);
+
 rtc_deinit(d);
 stdvga_deinit(d);
 vioapic_deinit(d);
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b1c376d455..b7f67f9f03 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1155,10 +1155,6 @@ static int svm_domain_initialise(struct domain *d)
 return 0;
 }
 
-static void svm_domain_destroy(struct domain *d)
-{
-}
-
 static int svm_vcpu_initialise(struct vcpu *v)
 {
 int rc;
@@ -2425,7 +2421,6 @@ static struct hvm_function_table __initdata 
svm_function_table = {
 .cpu_up   = svm_cpu_up,
 .cpu_down = svm_cpu_down,
 .domain_initialise= svm_domain_initialise,
-.domain_destroy   = svm_domain_destroy,
 .vcpu_initialise  = svm_vcpu_initialise,
 .vcpu_destroy = svm_vcpu_destroy,
 .save_cpu_ctxt= svm_save_vmcb_ctxt,
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 8706954d73..f76fdd4f96 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -420,7 +420,7 @@ static int vmx_domain_initialise(struct domain *d)
 return 0;
 }
 
-static void vmx_domain_destroy(struct domain *d)
+static void vmx_domain_relinquish_resources(struct domain *d)
 {
 if ( !has_vlapic(d) )
 return;
@@ -2241,7 +2241,7 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .cpu_up_prepare   = vmx_cpu_up_prepare,
 .cpu_dead = vmx_cpu_dead,
 .domain_initialise= vmx_domain_initialise,
-.domain_destroy   = vmx_domain_destroy,
+.domain_relinquish_resources = vmx_domain_relinquish_resources,
 .vcpu_initialise  = vmx_vcpu_initialise,
 .vcpu_destroy = vmx_vcpu_destroy,
 .save_cpu_ctxt= vmx_save_vmcs_ctxt,
@@ -3029,12 +3029,22 @@ static int vmx_alloc_vlapic_mapping(struct domain *d)
 if ( !cpu_has_vmx_virtualize_apic_accesses )
 return 0;
 
-pg = alloc_domheap_page(d, MEMF_no_owner);
+pg = alloc_domheap_page(d, 0);
 if ( !pg )
 return -ENOMEM;
+
+if ( !get_page_and_type(pg, d, PGT_writable_page) )
+{
+/*
+ * The domain can't possibly