[Xen-devel] [PATCH] x86/mmcfg: Remove redundant code in pci_mmcfg_reject_broken()
No functional change.
Signed-off-by: Zhenzhong Duan
---
xen/arch/x86/x86_64/mmconfig-shared.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/x86_64/mmconfig-shared.c
b/xen/arch/x86/x86_64/mmconfig-shared.c
index 7c3b7fd..4a6ca26 100644
--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -371,8 +371,6 @@ static bool_t __init pci_mmcfg_reject_broken(void)
(pci_mmcfg_config[0].address == 0))
return 0;
-cfg = _mmcfg_config[0];
-
for (i = 0; i < pci_mmcfg_config_num; i++) {
u64 addr, size;
--
1.7.3
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/mmcfg/drhd: Move acpi_mmcfg_init() before calling acpi_parse_dmar()
On a multiple pci segment system such as HPE Superdome-Flex, pci config space from nonzero segment is accessed with mmcfg during acpi parsing DMAR region. We need to setup mmcfg mapping before that or else drhd isn't correctly setup and devices under it fail to load in dom0. Signed-off-by: Zhenzhong Duan Tested-by: Gopalasetty, Manoj --- xen/arch/x86/setup.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 8301de8..9af7426 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1493,6 +1493,10 @@ void __init noreturn __start_xen(unsigned long mbi_p) generic_apic_probe(); +pt_pci_init(); + +acpi_mmcfg_init(); + acpi_boot_init(); if ( smp_found_config ) @@ -1596,12 +1600,8 @@ void __init noreturn __start_xen(unsigned long mbi_p) local_irq_enable(); -pt_pci_init(); - vesa_mtrr_init(); -acpi_mmcfg_init(); - early_msi_init(); iommu_setup();/* setup iommu if available */ -- 1.7.3 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125939: regressions - FAIL
flight 125939 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125939/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 125923
Tests which did not succeed, but are not blocking:
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 4cdb6bfde2300c75725b3e267469bd6c955e
baseline version:
xen 3dd454c6c694409aaedd4ed075d6aeace2dd8391
Last test of basis 125923 2018-08-15 16:00:41 Z0 days
Testing same since 125928 2018-08-15 19:00:49 Z0 days5 attempts
People who touched revisions under test:
Andrew Cooper
Christian Lindig
Daniel De Graaf
Julien Grall
Wei Liu
jobs:
build-amd64 pass
build-armhf fail
build-amd64-libvirt pass
test-armhf-armhf-xl blocked
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 4cdb6bfde2300c75725b3e267469bd6c955e
Author: Andrew Cooper
Date: Fri Mar 16 18:27:24 2018 +
xen/evtchn: Pass max_evtchn_port into evtchn_init()
... rather than setting it up once domain_create() has completed. This
involves constructing a default value for dom0.
No practical change in functionality.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Acked-by: Julien Grall
commit 4a83497635056d33fe20ef705f35617b1003a276
Author: Andrew Cooper
Date: Tue Feb 27 17:39:37 2018 +
xen/domctl: Merge set_max_evtchn into createdomain
set_max_evtchn is somewhat weird. It was introduced with the event_fifo
work,
but has never been used. Still, it is a bounding on resources consumed by
the
event channel infrastructure, and should be part of createdomain, rather
than
editable after the fact.
Drop XEN_DOMCTL_set_max_evtchn completely (including XSM hooks and libxc
wrappers), and retain the functionality in XEN_DOMCTL_createdomain.
Signed-off-by: Andrew Cooper
Acked-by: Daniel De Graaf
Acked-by: Christian Lindig
Acked-by: Wei Liu
Reviewed-by: Roger Pau Monné
commit 54ed251dc7b85565820019102e533afcea814e16
Author: Andrew Cooper
Date: Fri Mar 9 14:38:35 2018 +
tools: Rework xc_domain_create() to take a full xen_domctl_createdomain
In future patches, the structure will be extended with further information,
and this is far cleaner than adding extra parameters.
The python stubs are the only user which passes NULL for the existing config
option (which is actually the arch substructure). Therefore, the #ifdefary
moves to compensate.
For libxl, pass the full config object down into
libxl__arch_domain_{prepare,save}_config(), as there are in practice arch
specific settings in the common part of the structure (flags s3_integrity
and
oos_off specifically).
No practical change in behaviour.
Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
commit acc2a06c780e9e7ffa6373854735503b7d63a1d0
Author: Andrew Cooper
Date: Mon Mar 12 10:40:33 2018 +
tools/ocaml: Pass a full domctl_create_config into stub_xc_domain_create()
The underlying C function is about to make the same change, and the
structure
is going to gain extra fields.
Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 125904: tolerable FAIL - PUSHED
flight 125904 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125904/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass 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 13 migrate-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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linux1aa1166efaceef8972045b4aa25e6e0ab96d8a30 baseline version: linux1e92e813554a93741666e9f378a83d70405b9076 Last test of basis 125175 2018-07-15 08:04:36 Z 31 days Failing since125270 2018-07-17 10:10:13 Z 29 days 13 attempts Testing same since 125835 2018-08-10 01:41:17 Z6 days4 attempts 494 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumprun pass build-i386-rumprun pass test-amd64-amd64-xl
[Xen-devel] [xen-unstable-smoke test] 125936: regressions - FAIL
flight 125936 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125936/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 125923
Tests which did not succeed, but are not blocking:
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 4cdb6bfde2300c75725b3e267469bd6c955e
baseline version:
xen 3dd454c6c694409aaedd4ed075d6aeace2dd8391
Last test of basis 125923 2018-08-15 16:00:41 Z0 days
Testing same since 125928 2018-08-15 19:00:49 Z0 days4 attempts
People who touched revisions under test:
Andrew Cooper
Christian Lindig
Daniel De Graaf
Julien Grall
Wei Liu
jobs:
build-amd64 pass
build-armhf fail
build-amd64-libvirt pass
test-armhf-armhf-xl blocked
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 4cdb6bfde2300c75725b3e267469bd6c955e
Author: Andrew Cooper
Date: Fri Mar 16 18:27:24 2018 +
xen/evtchn: Pass max_evtchn_port into evtchn_init()
... rather than setting it up once domain_create() has completed. This
involves constructing a default value for dom0.
No practical change in functionality.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Acked-by: Julien Grall
commit 4a83497635056d33fe20ef705f35617b1003a276
Author: Andrew Cooper
Date: Tue Feb 27 17:39:37 2018 +
xen/domctl: Merge set_max_evtchn into createdomain
set_max_evtchn is somewhat weird. It was introduced with the event_fifo
work,
but has never been used. Still, it is a bounding on resources consumed by
the
event channel infrastructure, and should be part of createdomain, rather
than
editable after the fact.
Drop XEN_DOMCTL_set_max_evtchn completely (including XSM hooks and libxc
wrappers), and retain the functionality in XEN_DOMCTL_createdomain.
Signed-off-by: Andrew Cooper
Acked-by: Daniel De Graaf
Acked-by: Christian Lindig
Acked-by: Wei Liu
Reviewed-by: Roger Pau Monné
commit 54ed251dc7b85565820019102e533afcea814e16
Author: Andrew Cooper
Date: Fri Mar 9 14:38:35 2018 +
tools: Rework xc_domain_create() to take a full xen_domctl_createdomain
In future patches, the structure will be extended with further information,
and this is far cleaner than adding extra parameters.
The python stubs are the only user which passes NULL for the existing config
option (which is actually the arch substructure). Therefore, the #ifdefary
moves to compensate.
For libxl, pass the full config object down into
libxl__arch_domain_{prepare,save}_config(), as there are in practice arch
specific settings in the common part of the structure (flags s3_integrity
and
oos_off specifically).
No practical change in behaviour.
Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
commit acc2a06c780e9e7ffa6373854735503b7d63a1d0
Author: Andrew Cooper
Date: Mon Mar 12 10:40:33 2018 +
tools/ocaml: Pass a full domctl_create_config into stub_xc_domain_create()
The underlying C function is about to make the same change, and the
structure
is going to gain extra fields.
Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
(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 test] 125932: regressions - FAIL
flight 125932 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125932/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 125923
Tests which did not succeed, but are not blocking:
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 4cdb6bfde2300c75725b3e267469bd6c955e
baseline version:
xen 3dd454c6c694409aaedd4ed075d6aeace2dd8391
Last test of basis 125923 2018-08-15 16:00:41 Z0 days
Testing same since 125928 2018-08-15 19:00:49 Z0 days3 attempts
People who touched revisions under test:
Andrew Cooper
Christian Lindig
Daniel De Graaf
Julien Grall
Wei Liu
jobs:
build-amd64 pass
build-armhf fail
build-amd64-libvirt pass
test-armhf-armhf-xl blocked
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 4cdb6bfde2300c75725b3e267469bd6c955e
Author: Andrew Cooper
Date: Fri Mar 16 18:27:24 2018 +
xen/evtchn: Pass max_evtchn_port into evtchn_init()
... rather than setting it up once domain_create() has completed. This
involves constructing a default value for dom0.
No practical change in functionality.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Acked-by: Julien Grall
commit 4a83497635056d33fe20ef705f35617b1003a276
Author: Andrew Cooper
Date: Tue Feb 27 17:39:37 2018 +
xen/domctl: Merge set_max_evtchn into createdomain
set_max_evtchn is somewhat weird. It was introduced with the event_fifo
work,
but has never been used. Still, it is a bounding on resources consumed by
the
event channel infrastructure, and should be part of createdomain, rather
than
editable after the fact.
Drop XEN_DOMCTL_set_max_evtchn completely (including XSM hooks and libxc
wrappers), and retain the functionality in XEN_DOMCTL_createdomain.
Signed-off-by: Andrew Cooper
Acked-by: Daniel De Graaf
Acked-by: Christian Lindig
Acked-by: Wei Liu
Reviewed-by: Roger Pau Monné
commit 54ed251dc7b85565820019102e533afcea814e16
Author: Andrew Cooper
Date: Fri Mar 9 14:38:35 2018 +
tools: Rework xc_domain_create() to take a full xen_domctl_createdomain
In future patches, the structure will be extended with further information,
and this is far cleaner than adding extra parameters.
The python stubs are the only user which passes NULL for the existing config
option (which is actually the arch substructure). Therefore, the #ifdefary
moves to compensate.
For libxl, pass the full config object down into
libxl__arch_domain_{prepare,save}_config(), as there are in practice arch
specific settings in the common part of the structure (flags s3_integrity
and
oos_off specifically).
No practical change in behaviour.
Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
commit acc2a06c780e9e7ffa6373854735503b7d63a1d0
Author: Andrew Cooper
Date: Mon Mar 12 10:40:33 2018 +
tools/ocaml: Pass a full domctl_create_config into stub_xc_domain_create()
The underlying C function is about to make the same change, and the
structure
is going to gain extra fields.
Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 25/25] xen/arm: split domain_build.c
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi,
>
> On 01/08/18 00:28, Stefano Stabellini wrote:
> > domain_build.c is too large.
> >
> > Move all the ACPI specific device tree generating functions from
> > domain_build.c to acpi/acpi_dt_build.c.
>
> The directory is called "acpi" so there is no point to duplicate in the
> filename.
>
> Also, looking at the code moved, the name does not seem to be correct. Indeed
> you also generate ACPI tables. A better name for this file would be
> domain_build.c
OK
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > xen/arch/arm/acpi/Makefile| 1 +
> > xen/arch/arm/acpi/acpi_dt_build.c | 591
> > ++
> > xen/arch/arm/acpi/acpi_dt_build.h | 32 +++
> > xen/arch/arm/domain_build.c | 585
> > +
> > 4 files changed, 629 insertions(+), 580 deletions(-)
> > create mode 100644 xen/arch/arm/acpi/acpi_dt_build.c
> > create mode 100644 xen/arch/arm/acpi/acpi_dt_build.h
> >
> > diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
> > index 23963f8..ac0804b 100644
> > --- a/xen/arch/arm/acpi/Makefile
> > +++ b/xen/arch/arm/acpi/Makefile
> > @@ -1,2 +1,3 @@
> > obj-y += lib.o
> > +obj-y += acpi_dt_build.o
> > obj-y += boot.init.o
> > diff --git a/xen/arch/arm/acpi/acpi_dt_build.c
> > b/xen/arch/arm/acpi/acpi_dt_build.c
> > new file mode 100644
> > index 000..7e12d64
> > --- /dev/null
> > +++ b/xen/arch/arm/acpi/acpi_dt_build.c
> > @@ -0,0 +1,591 @@
>
> Missing copyright headers here.
OK
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Do we really need xen/irq.h and asm/irq.h?
No, I'll remove
> > +#include
> > +#include "acpi_dt_build.h"
> > +#include "../kernel.h"
>
> Urgh, that's a call to move kernel.h in asm-arm/.
OK
> > diff --git a/xen/arch/arm/acpi/acpi_dt_build.h
> > b/xen/arch/arm/acpi/acpi_dt_build.h
> > new file mode 100644
> > index 000..08e7aab
> > --- /dev/null
> > +++ b/xen/arch/arm/acpi/acpi_dt_build.h
> > @@ -0,0 +1,32 @@
> > +#ifndef __ARCH_ARM_ACPI_ACPI_DT_BUILD_H__
> > +#define __ARCH_ARM_ACPI_ACPI_DT_BUILD_H__
> > +
> > +#include
> > +#include "../kernel.h"
>
> See above.
OK
> > +
> > +int map_irq_to_domain(struct domain *d, unsigned int irq,
> > + bool need_mapping, const char *devname);
> > +int make_chosen_node(const struct kernel_info *kinfo);
> > +void evtchn_allocate(struct domain *d);
>
> Those one should be moved in an header domain_build.h in asm-arm.
OK
> > +
> > +#ifndef CONFIG_ACPI
> > +static inline int prepare_acpi(struct domain *d, struct kernel_info *kinfo)
> > +{
> > +/* Only booting with ACPI will hit here */
> > +BUG();
> > +return -EINVAL;
> > +}
> > +#else
> > +int prepare_acpi(struct domain *d, struct kernel_info *kinfo);
> > +#endif
>
> This one should go in asm-arm/acpi.h.
>
> So this header is not necessary anymore.
I was unable to add prepare_acpi to asm-arm/acpi.h because it causes a
#include dependency hell, I am thinking of adding it to asm-arm/domain_build.h.
In file included from /local/repos/xen-upstream/xen/include/xen/sched.h:11:0,
from /local/repos/xen-upstream/xen/include/asm/domain.h:5,
from /local/repos/xen-upstream/xen/include/asm/kernel.h:10,
from /local/repos/xen-upstream/xen/include/asm/acpi.h:27,
from
/local/repos/xen-upstream/xen/include/acpi/platform/aclinux.h:58,
from
/local/repos/xen-upstream/xen/include/acpi/platform/acenv.h:142,
from /local/repos/xen-upstream/xen/include/acpi/acpi.h:56,
from /local/repos/xen-upstream/xen/include/xen/acpi.h:33,
from pl011.c:307:
/local/repos/xen-upstream/xen/include/xen/domain.h:59:31: error: ‘struct
xen_domctl_createdomain’ declared inside parameter list will not be visible
outside of this definition or declaration [-Werror]
struct xen_domctl_createdomain *config);
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 125917: regressions - trouble: blocked/fail
flight 125917 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/125917/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 125317 Tests which did not succeed, but are not blocking: build-amd64-freebsd-again 1 build-check(1) blocked n/a version targeted for testing: freebsd dc5962723e41aa399f35f92a9f957ab47fea8fe7 baseline version: freebsd bf65d05707104df94117a293327d797d71a0118d Last test of basis 125317 2018-07-18 09:19:47 Z 28 days Failing since125467 2018-07-20 09:19:59 Z 26 days 12 attempts Testing same since 125917 2018-08-15 09:19:15 Z0 days1 attempts People who touched revisions under test: 0mp <0...@freebsd.org> ae alc allanjude andrew antoine araujo asomers avg bapt bde bdrewery br brd brooks bwidawsk bz cem cognet cperciva cy dab daichi davidcs delphij des dim dteske eadler emaste eugen fsu gallatin ganbold gavin gjb glebius gonzo hselasky ian imp jhb jhibbits jhixson jilles jkim jtl kevans kevlo kib kp leitao loos luporl lwhsu manu marius markj Mathy Vanhoef Matthew Ahrens mav mckusick mm mmacy mmel netchild np obrien oshogbo pfg phk pkelsey pstef rmacklem royger rpokala rrs sef sevan shurd sjg trasz truckman tsoome tuexen uqs will woodsb02 wulf zleslie jobs: build-amd64-freebsd-againblocked build-amd64-freebsd 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 12179 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree
Hi all,
On Mon, 30 Jul 2018 19:02:10 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> drivers/xen/gntdev.c
>
> between commit:
>
> 1d3145675538 ("xen/gntdev: Make private routines/structures accessible")
>
> from the xen-tip tree and commit:
>
> aaefcabe9c25 ("mm, oom: distinguish blockable mode for mmu notifiers")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/xen/gntdev.c
> index c866a62f766d,55b4f0e3f4d6..
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@@ -479,7 -441,20 +479,20 @@@ static const struct vm_operations_struc
>
> /* -- */
>
> -static bool in_range(struct grant_map *map,
> ++static bool in_range(struct gntdev_grant_map *map,
> + unsigned long start, unsigned long end)
> + {
> + if (!map->vma)
> + return false;
> + if (map->vma->vm_start >= end)
> + return false;
> + if (map->vma->vm_end <= start)
> + return false;
> +
> + return true;
> + }
> +
> -static void unmap_if_in_range(struct grant_map *map,
> +static void unmap_if_in_range(struct gntdev_grant_map *map,
> unsigned long start, unsigned long end)
> {
> unsigned long mstart, mend;
> @@@ -503,15 -472,26 +510,26 @@@
> WARN_ON(err);
> }
>
> - static void mn_invl_range_start(struct mmu_notifier *mn,
> + static int mn_invl_range_start(struct mmu_notifier *mn,
> struct mm_struct *mm,
> - unsigned long start, unsigned long end)
> + unsigned long start, unsigned long end,
> + bool blockable)
> {
> struct gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn);
> -struct grant_map *map;
> +struct gntdev_grant_map *map;
> + int ret = 0;
> +
> + /* TODO do we really need a mutex here? */
> + if (blockable)
> + mutex_lock(>lock);
> + else if (!mutex_trylock(>lock))
> + return -EAGAIN;
>
> - mutex_lock(>lock);
> list_for_each_entry(map, >maps, next) {
> + if (in_range(map, start, end)) {
> + ret = -EAGAIN;
> + goto out_unlock;
> + }
> unmap_if_in_range(map, start, end);
> }
> list_for_each_entry(map, >freeable_maps, next) {
This is now a conflict between Linus' tree and the akpm-current tree.
--
Cheers,
Stephen Rothwell
pgpVyemEAhotn.pgp
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.6-testing test] 125906: regressions - FAIL
flight 125906 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125906/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 6 xen-buildfail REGR. vs. 125705 test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail REGR. vs. 125705 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore.2 fail REGR. vs. 125705 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 125705 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 125705 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 125705 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125705 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125705 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125705 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125705 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 125705 test-xtf-amd64-amd64-1 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-1 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-5 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-3 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-1 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-5 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-3 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-4 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-4 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-2 37 xtf/test-hvm32pae-memop-seg fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-2 77 xtf/test-pv32pae-xsa-194 fail 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-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail 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 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: xen e1b03b03b199bd206c81286b4f51b6a681123eda baseline version: xen 98d7948b50b4e91ec4efa860da32d9ac4fe69300 Last test of basis 125705 2018-07-31 17:01:33 Z 15 days Testing same since 125906 2018-08-14 17:05:51 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Christian Lindig George Dunlap Jan Beulich Juergen Gross Kevin Tian Stefano Stabellini Wei Liu jobs: build-amd64-xsm pass build-i386-xsm
Re: [Xen-devel] [PATCH v3 22/25] xen/arm: Allow vpl011 to be used by DomU
On Mon, 13 Aug 2018, Julien Grall wrote:
> On 01/08/18 00:28, Stefano Stabellini wrote:
> > Make vpl011 being able to be used without a userspace component in Dom0.
> > In that case, output is printed to the Xen serial and input is received
> > from the Xen serial one character at a time.
> >
> > Call domain_vpl011_init during construct_domU if vpl011 is enabled.
> >
> > Introduce a new ring struct with only the ring array to avoid a waste of
> > memory. Introduce separate read_data and write_data functions for
> > initial domains: vpl011_write_data_xen is very simple and just writes
> > to the console, while vpl011_read_data_xen is a duplicate of
> > vpl011_read_data. Although textually almost identical, we are forced to
> > duplicate the functions because the struct layout is different.
> >
> > Output characters are printed one by one, potentially leading to
> > intermixed output of different domains on the console. A follow-up patch
> > will solve the issue by introducing buffering.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in v3:
> > - add in-code comments
> > - improve existing comments
> > - remove ifdef around domain_vpl011_init in construct_domU
> > - add ASSERT
> > - use SBSA_UART_FIFO_SIZE for in buffer size
> > - rename ring_enable to backend_in_domain
> > - rename struct xencons_in to struct vpl011_xen_backend
> > - rename inring field to xen
> > - rename helper functions accordingly
> > - remove unnecessary stub implementation of vpl011_rx_char
> > - move vpl011_rx_char_xen within the file to avoid the need of a forward
> >declaration of vpl011_data_avail
> > - fix small bug in vpl011_rx_char_xen: increment in_prod before using it
> >to check xencons_queued.
> >
> > Changes in v2:
> > - only init if vpl011
> > - rename vpl011_read_char to vpl011_rx_char
> > - remove spurious change
> > - fix coding style
> > - use different ring struct
> > - move the write_data changes to their own function
> >(vpl011_write_data_noring)
> > - duplicate vpl011_read_data
> > ---
> > xen/arch/arm/domain_build.c | 9 +-
> > xen/arch/arm/vpl011.c| 198
> > ++-
> > xen/include/asm-arm/vpl011.h | 8 ++
> > 3 files changed, 192 insertions(+), 23 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index f9fa484..0888a76 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2638,7 +2638,14 @@ static int __init construct_domU(struct domain *d,
> > struct dt_device_node *node)
> > if ( rc < 0 )
> > return rc;
> > -return __construct_domain(d, );
> > +rc = __construct_domain(d, );
> > +if ( rc < 0 )
> > +return rc;
> > +
> > +if ( kinfo.vpl011 )
> > +rc = domain_vpl011_init(d, NULL);
> > +
> > +return rc;
> > }
> > void __init create_domUs(void)
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index 725a203..f206c61 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -77,6 +77,91 @@ static void vpl011_update_interrupt_status(struct domain
> > *d)
> > #endif
> > }
> > +/*
> > + * vpl011_write_data_xen writes chars from the vpl011 out buffer to the
> > + * console. Only to be used when the backend is Xen.
> > + */
> > +static void vpl011_write_data_xen(struct domain *d, uint8_t data)
> > +{
> > +unsigned long flags;
> > +struct vpl011 *vpl011 = >arch.vpl011;
> > +
> > +VPL011_LOCK(d, flags);
> > +
> > +printk("%c", data);
> > +if (data == '\n')
> > +printk("DOM%u: ", d->domain_id);
> > +
> > +vpl011->uartris |= TXI;
> > +vpl011->uartfr &= ~TXFE;
> > +vpl011_update_interrupt_status(d);
> > +
> > +VPL011_UNLOCK(d, flags);
> > +}
> > +
> > +/*
> > + * vpl011_read_data_xen reads data when the backend is xen. Characters
> > + * are added to the vpl011 receive buffer by vpl011_rx_char_xen.
> > + */
> > +static uint8_t vpl011_read_data_xen(struct domain *d)
> > +{
> > +unsigned long flags;
> > +uint8_t data = 0;
> > +struct vpl011 *vpl011 = >arch.vpl011;
> > +struct vpl011_xen_backend *intf = vpl011->xen;
> > +XENCONS_RING_IDX in_cons, in_prod;
> > +
> > +VPL011_LOCK(d, flags);
> > +
> > +in_cons = intf->in_cons;
> > +in_prod = intf->in_prod;
> > +
> > +smp_rmb();
> > +
> > +/*
> > + * It is expected that there will be data in the ring buffer when this
> > + * function is called since the guest is expected to read the data
> > register
> > + * only if the TXFE flag is not set.
> > + * If the guest still does read when TXFE bit is set then 0 will be
> > returned.
> > + */
> > +if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) > 0 )
> > +{
> > +unsigned int fifo_level;
> > +
> > +data = intf->in[xencons_mask(in_cons, sizeof(intf->in))];
> > +in_cons += 1;
> > +smp_mb();
> > +intf->in_cons =
Re: [Xen-devel] [PATCH v3 20/25] xen/arm: introduce a union in vpl011
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/08/18 00:28, Stefano Stabellini wrote:
> > Introduce a union in struct vpl011 to contain the console ring members.
> > A later patch will add another member of the union for the case where
> > the backend is in Xen.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in v3:
> > - rename ring field to dom
> >
> > Changes in v2:
> > - new patch
> > ---
> > xen/arch/arm/vpl011.c| 20 ++--
> > xen/include/asm-arm/vpl011.h | 8 ++--
> > 2 files changed, 16 insertions(+), 12 deletions(-)
> >
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index a281eab..e70c5ec 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -82,7 +82,7 @@ static uint8_t vpl011_read_data(struct domain *d)
> > unsigned long flags;
> > uint8_t data = 0;
> > struct vpl011 *vpl011 = >arch.vpl011;
> > -struct xencons_interface *intf = vpl011->ring_buf;
> > +struct xencons_interface *intf = vpl011->dom.ring_buf;
> > XENCONS_RING_IDX in_cons, in_prod;
> > VPL011_LOCK(d, flags);
> > @@ -145,7 +145,7 @@ static uint8_t vpl011_read_data(struct domain *d)
> > static void vpl011_update_tx_fifo_status(struct vpl011 *vpl011,
> >unsigned int fifo_level)
> > {
> > -struct xencons_interface *intf = vpl011->ring_buf;
> > +struct xencons_interface *intf = vpl011->dom.ring_buf;
> > unsigned int fifo_threshold = sizeof(intf->out) -
> > SBSA_UART_FIFO_LEVEL;
> > BUILD_BUG_ON(sizeof(intf->out) < SBSA_UART_FIFO_SIZE);
> > @@ -164,7 +164,7 @@ static void vpl011_write_data(struct domain *d, uint8_t
> > data)
> > {
> > unsigned long flags;
> > struct vpl011 *vpl011 = >arch.vpl011;
> > -struct xencons_interface *intf = vpl011->ring_buf;
> > +struct xencons_interface *intf = vpl011->dom.ring_buf;
> > XENCONS_RING_IDX out_cons, out_prod;
> > VPL011_LOCK(d, flags);
> > @@ -382,7 +382,7 @@ static void vpl011_data_avail(struct domain *d)
> > {
> > unsigned long flags;
> > struct vpl011 *vpl011 = >arch.vpl011;
> > -struct xencons_interface *intf = vpl011->ring_buf;
> > +struct xencons_interface *intf = vpl011->dom.ring_buf;
> > XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
> > XENCONS_RING_IDX in_fifo_level, out_fifo_level;
> > @@ -459,14 +459,14 @@ int domain_vpl011_init(struct domain *d, struct
> > vpl011_init_info *info)
> > int rc;
> > struct vpl011 *vpl011 = >arch.vpl011;
> > -if ( vpl011->ring_buf )
> > +if ( vpl011->dom.ring_buf )
> > return -EINVAL;
> > /* Map the guest PFN to Xen address space. */
> > rc = prepare_ring_for_helper(d,
> > gfn_x(info->gfn),
> > - >ring_page,
> > - >ring_buf);
> > + >dom.ring_page,
> > + >dom.ring_buf);
> > if ( rc < 0 )
> > goto out;
> > @@ -495,7 +495,7 @@ out2:
> > vgic_free_virq(d, GUEST_VPL011_SPI);
> > out1:
> > -destroy_ring_for_helper(>ring_buf, vpl011->ring_page);
> > +destroy_ring_for_helper(>dom.ring_buf, vpl011->dom.ring_page);
> > out:
> > return rc;
> > @@ -505,11 +505,11 @@ void domain_vpl011_deinit(struct domain *d)
> > {
> > struct vpl011 *vpl011 = >arch.vpl011;
> > -if ( !vpl011->ring_buf )
> > +if ( !vpl011->dom.ring_buf )
> > return;
> > free_xen_event_channel(d, vpl011->evtchn);
> > -destroy_ring_for_helper(>ring_buf, vpl011->ring_page);
> > +destroy_ring_for_helper(>dom.ring_buf, vpl011->dom.ring_page);
> > }
> > /*
> > diff --git a/xen/include/asm-arm/vpl011.h b/xen/include/asm-arm/vpl011.h
> > index db95ff8..b873a29 100644
> > --- a/xen/include/asm-arm/vpl011.h
> > +++ b/xen/include/asm-arm/vpl011.h
> > @@ -31,8 +31,12 @@
> > #define SBSA_UART_FIFO_SIZE 32
> > struct vpl011 {
> > -void *ring_buf;
> > -struct page_info *ring_page;
> > +union {
>
> If you name the union vpl011_backend it would be clearer that this deal with
> backend information. Or even just avoiding the anonymous union by naming it
> "backend".
OK
> > +struct {
> > +void *ring_buf;
> > +struct page_info *ring_page;
> > +} dom;
> > +};
> > uint32_tuartfr; /* Flag register */
> > uint32_tuartcr; /* Control register */
> > uint32_tuartimsc; /* Interrupt mask register*/
> >
>
> 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 19/25] xen/arm: generate vpl011 node on device tree for domU
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/08/18 00:28, Stefano Stabellini wrote:
> > Introduce vpl011 support to guests started from Xen: it provides a
> > simple way to print output from a guest, as most guests come with a
> > pl011 driver. It is also able to provide a working console with
> > interrupt support.
> >
> > The UART exposed to the guest is a SBSA compatible UART and not a PL011.
> > SBSA UART is a subset of PL011 r1p5. A full PL011 implementation in Xen
> > would just be too difficult, so guests may require some drivers changes.
> >
> > Enable vpl011 conditionally if the user requested it.
> >
> > Make set_interrupt_ppi able to handle non-PPI and rename it
> > set_interrupt.
>
> It would have been better to have this change in a separate patch.
I'll separate it
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in v3:
> > - use bool
> > - retain BUG_ON(irq < 16)
> > - add vpl011 bool to kinfo
> > - return error of vpl011 is required but CONFIG_SBSA_VUART_CONSOLE is
> >missing
> >
> > Changes in v2:
> > - code style fixes
> > - make set_interrupt_ppi generic
> > - rename set_interrupt_ppi to set_interrupt
> > - only make the vpl011 node if the option was enabled
> > ---
> > xen/arch/arm/domain_build.c | 95
> > ++---
> > xen/arch/arm/kernel.h | 3 ++
> > 2 files changed, 83 insertions(+), 15 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 167a56e..f9fa484 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -619,19 +619,20 @@ static int __init write_properties(struct domain *d,
> > struct kernel_info *kinfo,
> > typedef __be32 gic_interrupt_t[3];
> > -static void __init set_interrupt_ppi(gic_interrupt_t interrupt,
> > - unsigned int irq,
> > - unsigned int cpumask,
> > - unsigned int level)
> > +static void __init set_interrupt(gic_interrupt_t interrupt,
> > + unsigned int irq,
> > + unsigned int cpumask,
> > + unsigned int level)
> > {
> > __be32 *cells = interrupt;
> > +bool is_ppi = !!(irq < 32);
> > BUG_ON(irq < 16);
> > -BUG_ON(irq >= 32);
> > +irq -= (is_ppi) ? 16: 32; /* PPIs start at 16, SPIs at 32 */
> > /* See linux
> > Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
> > -dt_set_cell(, 1, 1); /* is a PPI */
> > -dt_set_cell(, 1, irq - 16); /* PPIs start at 16 */
> > +dt_set_cell(, 1, is_ppi); /* is a PPI? */
> > +dt_set_cell(, 1, irq);
> > dt_set_cell(, 1, (cpumask << 8) | level);
> > }
> > @@ -752,7 +753,7 @@ static int __init make_hypervisor_node(struct domain
> > *d,
> >* - All CPUs
> >* TODO: Handle properly the cpumask;
> >*/
> > -set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > res = fdt_property_interrupts(fdt, , 1);
> > if ( res )
> > return res;
> > @@ -1029,15 +1030,15 @@ static int __init make_timer_node(const struct
> > domain *d, void *fdt,
> > irq = timer_get_irq(TIMER_PHYS_SECURE_PPI);
> > dt_dprintk(" Secure interrupt %u\n", irq);
> > -set_interrupt_ppi(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > irq = timer_get_irq(TIMER_PHYS_NONSECURE_PPI);
> > dt_dprintk(" Non secure interrupt %u\n", irq);
> > -set_interrupt_ppi(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > irq = timer_get_irq(TIMER_VIRT_PPI);
> > dt_dprintk(" Virt interrupt %u\n", irq);
> > -set_interrupt_ppi(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
> > res = fdt_property_interrupts(fdt, intrs, 3);
> > if ( res )
> > @@ -1605,9 +1606,9 @@ static int __init make_timer_domU_node(const struct
> > domain *d, void *fdt)
> > return res;
> > }
> > -set_interrupt_ppi(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > -set_interrupt_ppi(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > -set_interrupt_ppi(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > +set_interrupt(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf,
> > DT_IRQ_TYPE_LEVEL_LOW);
> > res = fdt_property(fdt, "interrupts", intrs, sizeof (intrs[0]) * 3);
> > if ( res )
> >
[Xen-devel] [xen-4.7-testing test] 125902: regressions - FAIL
flight 125902 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125902/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm broken in 125879 build-arm64-pvopsbroken in 125879 build-arm64 broken in 125879 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 125057 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-credit2 7 xen-boot fail in 125858 pass in 125902 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125858 pass in 125902 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 125858 pass in 125902 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore.2 fail in 125879 pass in 125902 test-armhf-armhf-xl-arndale 19 leak-check/check fail in 125879 pass in 125902 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 125708 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 125858 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass in 125858 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 125879 Regressions which are regarded as allowable (not blocking): build-arm64 2 hosts-allocate broken in 125879 REGR. vs. 125057 build-arm64-pvops 2 hosts-allocate broken in 125879 REGR. vs. 125057 build-arm64-xsm 2 hosts-allocate broken in 125879 REGR. vs. 125057 Tests which did not succeed, but are not blocking: build-arm64-libvirt 1 build-check(1) blocked in 125879 n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked in 125879 n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 125879 n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked in 125879 n/a test-arm64-arm64-xl 1 build-check(1) blocked in 125879 n/a build-arm64 3 capture-logs broken in 125879 blocked in 125057 build-arm64-pvops3 capture-logs broken in 125879 blocked in 125057 build-arm64-xsm 3 capture-logs broken in 125879 blocked in 125057 test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 125708 never pass test-arm64-arm64-xl 13 migrate-support-check fail in 125708 never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail in 125708 never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 125708 never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 125708 never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 125708 never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail in 125708 never pass test-arm64-arm64-xl 14 saverestore-support-check fail in 125708 never pass test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125879 like 125057 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125057 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125057 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125057 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125057 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125057 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125057 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 125057 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 125057 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125057 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 125057 test-amd64-amd64-xl-rtds 10 debian-install fail like 125057 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125057 test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 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-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail
[Xen-devel] [xen-unstable-smoke test] 125930: regressions - FAIL
flight 125930 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 125923
Tests which did not succeed, but are not blocking:
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 4cdb6bfde2300c75725b3e267469bd6c955e
baseline version:
xen 3dd454c6c694409aaedd4ed075d6aeace2dd8391
Last test of basis 125923 2018-08-15 16:00:41 Z0 days
Testing same since 125928 2018-08-15 19:00:49 Z0 days2 attempts
People who touched revisions under test:
Andrew Cooper
Christian Lindig
Daniel De Graaf
Julien Grall
Wei Liu
jobs:
build-amd64 pass
build-armhf fail
build-amd64-libvirt pass
test-armhf-armhf-xl blocked
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 4cdb6bfde2300c75725b3e267469bd6c955e
Author: Andrew Cooper
Date: Fri Mar 16 18:27:24 2018 +
xen/evtchn: Pass max_evtchn_port into evtchn_init()
... rather than setting it up once domain_create() has completed. This
involves constructing a default value for dom0.
No practical change in functionality.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Acked-by: Julien Grall
commit 4a83497635056d33fe20ef705f35617b1003a276
Author: Andrew Cooper
Date: Tue Feb 27 17:39:37 2018 +
xen/domctl: Merge set_max_evtchn into createdomain
set_max_evtchn is somewhat weird. It was introduced with the event_fifo
work,
but has never been used. Still, it is a bounding on resources consumed by
the
event channel infrastructure, and should be part of createdomain, rather
than
editable after the fact.
Drop XEN_DOMCTL_set_max_evtchn completely (including XSM hooks and libxc
wrappers), and retain the functionality in XEN_DOMCTL_createdomain.
Signed-off-by: Andrew Cooper
Acked-by: Daniel De Graaf
Acked-by: Christian Lindig
Acked-by: Wei Liu
Reviewed-by: Roger Pau Monné
commit 54ed251dc7b85565820019102e533afcea814e16
Author: Andrew Cooper
Date: Fri Mar 9 14:38:35 2018 +
tools: Rework xc_domain_create() to take a full xen_domctl_createdomain
In future patches, the structure will be extended with further information,
and this is far cleaner than adding extra parameters.
The python stubs are the only user which passes NULL for the existing config
option (which is actually the arch substructure). Therefore, the #ifdefary
moves to compensate.
For libxl, pass the full config object down into
libxl__arch_domain_{prepare,save}_config(), as there are in practice arch
specific settings in the common part of the structure (flags s3_integrity
and
oos_off specifically).
No practical change in behaviour.
Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
commit acc2a06c780e9e7ffa6373854735503b7d63a1d0
Author: Andrew Cooper
Date: Mon Mar 12 10:40:33 2018 +
tools/ocaml: Pass a full domctl_create_config into stub_xc_domain_create()
The underlying C function is about to make the same change, and the
structure
is going to gain extra fields.
Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Ping: [PATCH] xen/ACPI: don't upload Px/Cx data for disabled processors
On 08/15/2018 03:55 AM, Rafael J. Wysocki wrote: > On Wed, Aug 15, 2018 at 8:44 AM Jan Beulich wrote: > On 25.06.18 at 12:17, wrote: >>> This is unnecessary and triggers a warning in the hypervisor. >>> >>> Often systems have more processor entries in their ACPI tables than are >>> actually installed/active. The ACPI_STA_DEVICE_PRESENT bit cannot be >>> reliably used, but the ACPI_MADT_ENABLED bit can. In order to not >>> introduce new functions in the main ACPI processor driver code, simply >>> use acpi_get_phys_id(), which does more than we need, but which checks >>> the MADT enabled bit in the process. Any CPU for which we can't >>> determine the APIC ID is unlikely to work properly anyway, so the extra >>> checks done by acpi_get_phys_id() should do no harm. >>> >>> Signed-off-by: Jan Beulich >>> --- >>> drivers/acpi/processor_core.c|1 + >>> drivers/xen/xen-acpi-processor.c |6 ++ >>> 2 files changed, 7 insertions(+) >> With Jürgen's R-b in place, may I ask for an ack for the processor_core.c >> change, or - in case you dislike the new export - an alternative suggestion? > It is fine to export it IMO. If you need my ACK for that, please feel > free to add it to the patch. Applied to for-linus-4.19. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/Xen: further refine add_preferred_console() invocations
On 07/02/2018 10:38 AM, Juergen Gross wrote: > On 25/06/18 12:45, Jan Beulich wrote: >> As the sequence of invocations matters, add "tty" only after "hvc" when >> a VGA console is available (which is often the case for Dom0, but hardly >> ever for DomU). >> >> Signed-off-by: Jan Beulich > Reviewed-by: Juergen Gross > Applied to for-linus-4.19. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RESEND] xen/mcelog: eliminate redundant setting of interface version
On 07/02/2018 09:52 AM, Juergen Gross wrote: > On 25/06/18 12:19, Jan Beulich wrote: >> This already gets done in HYPERVISOR_mca(). >> >> Signed-off-by: Jan Beulich > Reviewed-by: Juergen Gross > Applied to for-linus-4.19. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/Xen: mark xen_setup_gdt() __init
On 07/02/2018 09:54 AM, Juergen Gross wrote: > On 25/06/18 12:34, Jan Beulich wrote: >> Its only caller is __init, so to avoid section mismatch warnings when a >> compiler decides to not inline the function marke this function so as >> well. Take the opportunity and also make the function actually use its >> argument: The sole caller passes in zero anyway. >> >> Signed-off-by: Jan Beulich > Reviewed-by: Juergen Gross Applied to for-linus-4.19. -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 18/25] xen/arm: generate a simple device tree for domUs
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/08/18 00:28, Stefano Stabellini wrote:
> > Introduce functions to generate a basic domU device tree, similar to the
> > existing functions in tools/libxl/libxl_arm.c.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in v3:
> > - remove CONFIG_ACPI for make_chosen_node
> > - remove make_hypervisor_node until all Xen related functionalities
> >(evtchns, grant table, etc.) work correctly
> >
> > Changes in v2:
> > - move prepare_dtb rename to previous patch
> > - use switch for the gic version
> > - use arm,gic-400 instead of arm,cortex-a15-gic
> > - add @unit-address in the gic node name
> > - add comment on DOMU_DTB_SIZE
> > ---
> > xen/arch/arm/domain_build.c | 211
> > +++-
> > 1 file changed, 209 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index dfa74e4..167a56e 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1057,7 +1057,6 @@ static int __init make_timer_node(const struct domain
> > *d, void *fdt,
> > return res;
> > }
> > -#ifdef CONFIG_ACPI
> > /*
> >* This function is used as part of the device tree generation for Dom0
> >* on ACPI systems, and DomUs started directly from Xen based on device
> > @@ -1103,7 +1102,6 @@ static int __init make_chosen_node(const struct
> > kernel_info *kinfo)
> > return res;
> > }
> > -#endif
> > static int __init map_irq_to_domain(struct domain *d, unsigned int irq,
> > bool need_mapping, const char
> > *devname)
> > @@ -1496,6 +1494,211 @@ static int __init handle_node(struct domain *d,
> > struct kernel_info *kinfo,
> > return res;
> > }
> > +static int __init make_gic_domU_node(const struct domain *d, void *fdt,
> > int addrcells, int sizecells)
> > +{
> > +int res = 0;
> > +int reg_size = addrcells + sizecells;
> > +int nr_cells = reg_size * 2;
> > +__be32 reg[nr_cells];
> > +__be32 *cells;
>
> You are trying to be save a few lines by handling both GICv2 and GICv3 node in
> a single function. But this only thing it adds is confusion when reading the
> code.
>
> Please have two functions (one for each GIC version) to generate the DT. This
> would also help to add ITS/GICv2m support in the future.
OK
> > +
> > +switch ( gic_hw_version() )
> > +{
> > +case GIC_V3:
> > +res = fdt_begin_node(fdt,
> > "interrupt-controller@"__stringify(GUEST_GICV3_GICD_BASE));
> > +break;
> > +case GIC_V2:
> > +res = fdt_begin_node(fdt,
> > "interrupt-controller@"__stringify(GUEST_GICD_BASE));
> > +break;
> > +default:
> > +panic("Unsupported GIC version");
> > +}
> > +
> > +if ( res )
> > +return res;
> > +
> > +res = fdt_property_cell(fdt, "#address-cells", 0);
> > +if ( res )
> > +return res;
> > +
> > +res = fdt_property_cell(fdt, "#interrupt-cells", 3);
> > +if ( res )
> > +return res;
> > +
> > +res = fdt_property(fdt, "interrupt-controller", NULL, 0);
> > +if ( res )
> > +return res;
> > +
> > +switch ( gic_hw_version() )
> > +{
> > +case GIC_V3:
> > +{
> > +const uint64_t gicd_base = GUEST_GICV3_GICD_BASE;
> > +const uint64_t gicd_size = GUEST_GICV3_GICD_SIZE;
> > +const uint64_t gicr0_base = GUEST_GICV3_GICR0_BASE;
> > +const uint64_t gicr0_size = GUEST_GICV3_GICR0_SIZE;
>
> I am not entirely convinced of the usefulness of those variables.
I can remove
> > +
> > +res = fdt_property_string(fdt, "compatible", "arm,gic-v3");
> > +if ( res )
> > +return res;
> > +
> > +cells = [0];
> > +dt_child_set_range(, addrcells, sizecells, gicd_base,
> > gicd_size);
> > +dt_child_set_range(, addrcells, sizecells, gicr0_base,
> > gicr0_size);
> > +res = fdt_property(fdt, "reg", reg, sizeof(reg));
> > +break;
> > +}
> > +case GIC_V2:
> > +{
> > +const uint64_t gicd_base = GUEST_GICD_BASE;
> > +const uint64_t gicd_size = GUEST_GICD_SIZE;
> > +const uint64_t gicc_base = GUEST_GICC_BASE;
> > +const uint64_t gicc_size = GUEST_GICC_SIZE;
>
> Same here.
>
> > +
> > +res = fdt_property_string(fdt, "compatible", "arm,gic-400");
> > +if ( res )
> > +return res;
> > +
> > +cells = [0];
> > +dt_child_set_range(, addrcells, sizecells, gicd_base,
> > gicd_size);
> > +dt_child_set_range(, addrcells, sizecells, gicc_base,
> > gicc_size);
> > +break;
> > +}
> > +default:
> > +break;
> > +}
> > +
> > +res = fdt_property(fdt, "reg", reg, sizeof(reg));
> > +if (res)
> > +return res;
> > +
> > +res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
> > +if (res)
> > +
[Xen-devel] [xen-unstable-smoke test] 125928: regressions - FAIL
flight 125928 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125928/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 125923
Tests which did not succeed, but are not blocking:
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 4cdb6bfde2300c75725b3e267469bd6c955e
baseline version:
xen 3dd454c6c694409aaedd4ed075d6aeace2dd8391
Last test of basis 125923 2018-08-15 16:00:41 Z0 days
Testing same since 125928 2018-08-15 19:00:49 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Christian Lindig
Daniel De Graaf
Julien Grall
Wei Liu
jobs:
build-amd64 pass
build-armhf fail
build-amd64-libvirt pass
test-armhf-armhf-xl blocked
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
commit 4cdb6bfde2300c75725b3e267469bd6c955e
Author: Andrew Cooper
Date: Fri Mar 16 18:27:24 2018 +
xen/evtchn: Pass max_evtchn_port into evtchn_init()
... rather than setting it up once domain_create() has completed. This
involves constructing a default value for dom0.
No practical change in functionality.
Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Acked-by: Julien Grall
commit 4a83497635056d33fe20ef705f35617b1003a276
Author: Andrew Cooper
Date: Tue Feb 27 17:39:37 2018 +
xen/domctl: Merge set_max_evtchn into createdomain
set_max_evtchn is somewhat weird. It was introduced with the event_fifo
work,
but has never been used. Still, it is a bounding on resources consumed by
the
event channel infrastructure, and should be part of createdomain, rather
than
editable after the fact.
Drop XEN_DOMCTL_set_max_evtchn completely (including XSM hooks and libxc
wrappers), and retain the functionality in XEN_DOMCTL_createdomain.
Signed-off-by: Andrew Cooper
Acked-by: Daniel De Graaf
Acked-by: Christian Lindig
Acked-by: Wei Liu
Reviewed-by: Roger Pau Monné
commit 54ed251dc7b85565820019102e533afcea814e16
Author: Andrew Cooper
Date: Fri Mar 9 14:38:35 2018 +
tools: Rework xc_domain_create() to take a full xen_domctl_createdomain
In future patches, the structure will be extended with further information,
and this is far cleaner than adding extra parameters.
The python stubs are the only user which passes NULL for the existing config
option (which is actually the arch substructure). Therefore, the #ifdefary
moves to compensate.
For libxl, pass the full config object down into
libxl__arch_domain_{prepare,save}_config(), as there are in practice arch
specific settings in the common part of the structure (flags s3_integrity
and
oos_off specifically).
No practical change in behaviour.
Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
commit acc2a06c780e9e7ffa6373854735503b7d63a1d0
Author: Andrew Cooper
Date: Mon Mar 12 10:40:33 2018 +
tools/ocaml: Pass a full domctl_create_config into stub_xc_domain_create()
The underlying C function is about to make the same change, and the
structure
is going to gain extra fields.
Signed-off-by: Andrew Cooper
Acked-by: Christian Lindig
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 16/25] xen/arm: rename allocate_memory to allocate_memory_11
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi,
>
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > allocate_memory only deals with directly mapped memory. Rename it to
> > allocate_memory_11.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v3:
> > - add patch
> > ---
> > xen/arch/arm/domain_build.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 066dd75..ab72c36 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -244,7 +244,8 @@ fail:
> >* (as described above) we allow higher allocations and continue until
> >* that runs out (or we have allocated sufficient dom0 memory).
> >*/
> > -static void __init allocate_memory(struct domain *d, struct kernel_info
> > *kinfo)
> > +static void __init allocate_memory_11(struct domain *d,
> > + struct kernel_info *kinfo)
> > {
> > const unsigned int min_low_order =
> > get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
> > @@ -2240,7 +2241,7 @@ static int __init construct_domU(struct domain *d,
> > struct dt_device_node *node)
> > /* type must be set before allocate memory */
> > d->arch.type = kinfo.type;
> > #endif
> > -allocate_memory(d, );
> > +allocate_memory_11(d, );
>
> I don't think your patches are correctly ordered. This is adding a lot of
> confusion in the review because the DomU memory layout is fixed, yet here you
> rename the function to 1:1 mapping.
>
> Most likely you want to do add the new memory function before introducing
> DomU.
If I do that there will be no callers for the new function and
compilation fails. Bisectibility is the reason why I had to reorder the
patches.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 14/25] xen/arm: introduce construct_domU
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi,
>
> Title: You don't really introduce "construct_domU". You implement it. So a
> better title would be "Implement construct_domU".
OK
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > Similar to construct_dom0, construct_domU creates a barebone DomU guest.
> >
> > The device tree node passed as argument is compatible "xen,domain", see
> > docs/misc/arm/device-tree/booting.txt.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v3:
> > - move setting type before allocate_memory
> > - add ifdef around it and a comment
> >
> > Changes in v2:
> > - rename mem to memory
> > - make cpus and memory mandatory
> > - remove wront comment from commit message
> > - cpus and memory are read as integers
> > - read the vpl011 option
> > ---
> > xen/arch/arm/domain_build.c | 36 +++-
> > 1 file changed, 35 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 8f7ac54..101cca2 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2208,7 +2208,41 @@ static int __init __construct_domain(struct domain
> > *d, struct kernel_info *kinfo
> > static int __init construct_domU(struct domain *d, struct dt_device_node
> > *node)
> > {
> > -return 0;
> > +struct kernel_info kinfo = {};
> > +int rc;
> > +u32 mem;
> > +
> > +printk("*** LOADING DOMU ***\n");
> > +
> > +rc = dt_property_read_u32(node, "cpus", >max_vcpus);
> > +if ( !rc )
> > +return -EINVAL;
>
> For a user PoV this will be difficult to differentiate between the -EINVAL
> here and the only below.
>
> It is probably useful to log some error message. Similarly you might want to
> add some print telling the information about the domain created.
OK
> > +
> > +rc = dt_property_read_u32(node, "memory", );
>
> I don't think 32-bit integer is going to be enough to cover all the case.
> Nowadays Arm supports up to 52-bits Address-Space.
>
> So it would be best to cover all the case and use 64-bit here. That would also
> mean updating the documentation.
We need to support the whole address space, but unfortunately it means
have to add one more cell to the memory attribute, becoming less
intuitive to write. Even if we switched from KB to MB for the unit, we
would still need two cells from my calculations.
Are you sure I cannot convince you to switch to a string format for the
memory attribute where users can specify the unit (KB, MB, GB, etc.),
like they do today with the mem= command line?
> > +if ( !rc ) > +return -EINVAL;
> > +kinfo.unassigned_mem = (paddr_t)mem << 10;
>
> kinfo.unassigned_mem = KB(mem);
KB() only works for numbers, it is defined as: (_AC(_kb, ULL) << 10)
> > +
> > +d->vcpu = xzalloc_array(struct vcpu *, d->max_vcpus);
> > +if ( !d->vcpu )
> > +return -ENOMEM;;
> > +if ( alloc_vcpu(d, 0, 0) == NULL )
> > +return -ENOMEM;
> > +d->max_pages = ~0U;
> > +
> > +kinfo.d = d;
> > +
> > +rc = kernel_probe(, node);
> > +if ( rc < 0 )
> > +return rc;
> > +
> > +#ifdef CONFIG_ARM_64
> > +/* type must be set before allocate memory */
> > +d->arch.type = kinfo.type;
> > +#endif
> > +allocate_memory(d, );
> > +
> > +return __construct_domain(d, );
> > }
> > void __init create_domUs(void)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 13/25] xen/arm: introduce create_domUs
On Mon, 13 Aug 2018, Julien Grall wrote:
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > Call a new function, "create_domUs", from setup_xen to start DomU VMs.
> >
> > Introduce support for the "xen,domU" compatible node on device tree.
> > Create new DomU VMs based on the information found on device tree under
> > "xen,domU". Calls construct_domU for each domain.
> >
> > Introduce a simple global variable named max_init_domid to keep track of
> > the initial allocated domids. It holds the max domid among the initial
> > domains.
> >
> > Move the discard_initial_modules after DomUs have been built.
> >
> > First create domUs, then start dom0 -- no point in trying to start dom0
> > when the cpu is busy.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: andrew.coop...@citrix.com
> > CC: jbeul...@suse.com
> > ---
> > Changes in v3:
> > - move patch earlier and introduce empty construct_domU to fix bisection
> >builds
> > - fix max_init_domid to actually hold the max domid among initial
> >domains (instead of max_domid + 1)
> > - move domain_unpause_by_systemcontroller(dom0) after creating domUs
> >
> > Changes in v2:
> > - coding style
> > - set nr_spis to 32
> > - introduce create_domUs
> > ---
> > xen/arch/arm/domain_build.c | 42
> > +++---
> > xen/arch/arm/setup.c| 7 ++-
> > xen/include/asm-arm/setup.h | 3 +++
> > xen/include/asm-x86/setup.h | 2 ++
> > 4 files changed, 50 insertions(+), 4 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 0835340..8f7ac54 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -7,6 +7,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -2205,6 +2206,43 @@ static int __init __construct_domain(struct domain
> > *d, struct kernel_info *kinfo
> > return 0;
> > }
> > +static int __init construct_domU(struct domain *d, struct dt_device_node
> > *node)
> > +{
> > +return 0;
> > +}
> > +
> > +void __init create_domUs(void)
> > +{
> > +struct dt_device_node *node;
> > +struct dt_device_node *chosen = dt_find_node_by_name(dt_host,
> > "chosen");
> > +
> > +if ( chosen != NULL )
> > +{
> > +dt_for_each_child_node(chosen, node)
> > +{
> > +struct domain *d;
> > +struct xen_domctl_createdomain d_cfg = {
> > +.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
> > +.arch.nr_spis = 32,
>
> AFAICT, when creating DomU from the toolstack nr_spis will be 0. So why 32
> here?
Legacy from debug code. It should be 0, unless vpl011 is enabled, in
which case it should be 1.
> > +};
> > +
> > +if ( !dt_device_is_compatible(node, "xen,domain") )
> > +continue;
> > +
> > +d = domain_create(++max_init_domid, _cfg, false);
> > +if ( IS_ERR(d) )
> > +panic("Error creating domain %s", dt_node_name(node));
> > +
> > +d->is_console = 1;
> > +
> > +if ( construct_domU(d, node) != 0 )
> > +panic("Could not set up domain %s", dt_node_name(node));
> > +
> > +domain_unpause_by_systemcontroller(d);
> > +}
> > +}
> > +}
> > +
> > int __init construct_dom0(struct domain *d)
> > {
> > const struct bootcmdline *kernel =
> > boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
> > @@ -2258,9 +2296,7 @@ int __init construct_dom0(struct domain *d)
> > return rc;
> > -rc = __construct_domain(d, );
> > -discard_initial_modules();
> > -return rc;
> > +return __construct_domain(d, );
> > }
> > /*
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index c320df9..096484f 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -63,8 +63,11 @@ static unsigned long opt_xenheap_megabytes __initdata;
> > integer_param("xenheap_megabytes", opt_xenheap_megabytes);
> > #endif
> > +domid_t __read_mostly max_init_domid = 0;
> > +
> > static __used void init_done(void)
> > {
> > +discard_initial_modules();
> > free_init_memory();
> > startup_cpu_idle_loop();
> > }
> > @@ -894,7 +897,7 @@ void __init start_xen(unsigned long boot_phys_offset,
> > dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> > dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
> > -dom0 = domain_create(0, _cfg, true);
> > +dom0 = domain_create(max_init_domid, _cfg, true);
> > if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
> > panic("Error creating domain 0");
> > @@ -915,6 +918,8 @@ void __init start_xen(unsigned long boot_phys_offset,
> > /* Must be done past setting system_state. */
> > unregister_init_virtual_region();
> > +create_domUs();
> > +
> > domain_unpause_by_systemcontroller(dom0);
> > /*
Re: [Xen-devel] [PATCH v3 13/25] xen/arm: introduce create_domUs
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > Call a new function, "create_domUs", from setup_xen to start DomU VMs.
> >
> > Introduce support for the "xen,domU" compatible node on device tree.
> > Create new DomU VMs based on the information found on device tree under
> > "xen,domU". Calls construct_domU for each domain.
> >
> > Introduce a simple global variable named max_init_domid to keep track of
> > the initial allocated domids. It holds the max domid among the initial
> > domains.
> >
> > Move the discard_initial_modules after DomUs have been built.
> >
> > First create domUs, then start dom0 -- no point in trying to start dom0
> > when the cpu is busy.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: andrew.coop...@citrix.com
> > CC: jbeul...@suse.com
> > ---
> > Changes in v3:
> > - move patch earlier and introduce empty construct_domU to fix bisection
> >builds
> > - fix max_init_domid to actually hold the max domid among initial
> >domains (instead of max_domid + 1)
> > - move domain_unpause_by_systemcontroller(dom0) after creating domUs
> >
> > Changes in v2:
> > - coding style
> > - set nr_spis to 32
> > - introduce create_domUs
> > ---
> > xen/arch/arm/domain_build.c | 42
> > +++---
> > xen/arch/arm/setup.c| 7 ++-
> > xen/include/asm-arm/setup.h | 3 +++
> > xen/include/asm-x86/setup.h | 2 ++
> > 4 files changed, 50 insertions(+), 4 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 0835340..8f7ac54 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -7,6 +7,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -2205,6 +2206,43 @@ static int __init __construct_domain(struct domain
> > *d, struct kernel_info *kinfo
> > return 0;
> > }
> > +static int __init construct_domU(struct domain *d, struct dt_device_node
> > *node)
>
> AFAICT, the node is not going to be modified. So it should be const here.
OK
> > +{
> > +return 0;
>
> As Jan said, this should return an error until it is been implemented.
OK
> > +}
> > +
> > +void __init create_domUs(void)
> > +{
> > +struct dt_device_node *node;
> > +struct dt_device_node *chosen = dt_find_node_by_name(dt_host,
> > "chosen");
>
> Same here, you want them to be const.
OK
> > +
> > +if ( chosen != NULL )
>
> I would prefer if we don't introduce another indentation level by inverting
> the condition.
>
> Also, it is very unlikely to not have the chosen node. So it might be better
> to turn this into a panic/BUG_ON.
OK
> > +{
> > +dt_for_each_child_node(chosen, node)
> > +{
> > +struct domain *d;
> > +struct xen_domctl_createdomain d_cfg = {
> > +.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
> > +.arch.nr_spis = 32,
> > +};
> > +
> > +if ( !dt_device_is_compatible(node, "xen,domain") )
> > +continue;
> > +
> > +d = domain_create(++max_init_domid, _cfg, false);
> > +if ( IS_ERR(d) )
> > +panic("Error creating domain %s", dt_node_name(node));
> > +
> > +d->is_console = 1;
> > +
> > +if ( construct_domU(d, node) != 0 )
> > +panic("Could not set up domain %s", dt_node_name(node));
> > +
> > +domain_unpause_by_systemcontroller(d);
> > +}
> > +}
> > +}
> > +
> > int __init construct_dom0(struct domain *d)
> > {
> > const struct bootcmdline *kernel =
> > boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
> > @@ -2258,9 +2296,7 @@ int __init construct_dom0(struct domain *d)
> > return rc;
> > -rc = __construct_domain(d, );
> > -discard_initial_modules();
> > -return rc;
> > +return __construct_domain(d, );
> > }
> > /*
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index c320df9..096484f 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -63,8 +63,11 @@ static unsigned long opt_xenheap_megabytes __initdata;
> > integer_param("xenheap_megabytes", opt_xenheap_megabytes);
> > #endif
> > +domid_t __read_mostly max_init_domid = 0;
> > +
> > static __used void init_done(void)
> > {
> > +discard_initial_modules();
> > free_init_memory();
> > startup_cpu_idle_loop();
> > }
> > @@ -894,7 +897,7 @@ void __init start_xen(unsigned long boot_phys_offset,
> > dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> > dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
> > -dom0 = domain_create(0, _cfg, true);
> > +dom0 = domain_create(max_init_domid, _cfg, true);
> > if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
> > panic("Error creating domain 0");
> > @@
Re: [Xen-devel] [PATCH v3 12/25] xen/arm: refactor construct_dom0
On Mon, 13 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/08/18 00:27, Stefano Stabellini wrote:
> > Move generic initializations out of construct_dom0 so that they can be
> > reused.
> >
> > Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion.
> >
> > No functional changes in this patch.
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v3:
> > - move setting type before allocate_memory
> > - add ifdef around it and a comment
> > Changes in v2:
> > - move discard_initial_modules() after __construct_domain()
> > - remove useless blank line
> > - leave safety BUG_ONs in __construct_domain
> > - rename prepare_dtb to prepare_dtb_hwdom
> > ---
> > xen/arch/arm/domain_build.c | 128
> >
> > 1 file changed, 70 insertions(+), 58 deletions(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 8d82849..0835340 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1371,7 +1371,7 @@ static int __init handle_node(struct domain *d, struct
> > kernel_info *kinfo,
> > return res;
> > }
> > -static int __init prepare_dtb(struct domain *d, struct kernel_info
> > *kinfo)
> > +static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info
> > *kinfo)
> > {
> > const p2m_type_t default_p2mt = p2m_mmio_direct_c;
> > const void *fdt;
> > @@ -2106,75 +2106,31 @@ static void __init find_gnttab_region(struct domain
> > *d,
> > kinfo->gnttab_start, kinfo->gnttab_start + kinfo->gnttab_size);
> > }
> > -int __init construct_dom0(struct domain *d)
> > +static int __init __construct_domain(struct domain *d, struct kernel_info
> > *kinfo)
> > {
> > -const struct bootcmdline *kernel =
> > boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
> > -struct kernel_info kinfo = {};
> > struct vcpu *saved_current;
> > -int rc, i, cpu;
> > -
> > +int i, cpu;
> > +struct cpu_user_regs *regs;
> > struct vcpu *v = d->vcpu[0];
> > -struct cpu_user_regs *regs = >arch.cpu_info->guest_cpu_user_regs;
>
> There is no need to rewrite that line in
>
> struct cpu_user_regs *regs;
>
> regs = ...;
OK
> > -/* Sanity! */
> > -BUG_ON(d->domain_id != 0);
> > BUG_ON(d->vcpu[0] == NULL);
> > BUG_ON(v->is_initialised);
> > -printk("*** LOADING DOMAIN 0 ***\n");
> > -if ( dom0_mem <= 0 )
> > -{
> > -warning_add("PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR
> > NOW\n");
> > -dom0_mem = MB(512);
> > -}
> > -
> > -
> > -iommu_hwdom_init(d);
> > -
> > -d->max_pages = ~0U;
> > -
> > -kinfo.unassigned_mem = dom0_mem;
> > -kinfo.d = d;
> > -
> > -rc = kernel_probe(, NULL);
> > -if ( rc < 0 )
> > -return rc;
> > +regs = >arch.cpu_info->guest_cpu_user_regs;
> > #ifdef CONFIG_ARM_64
> > /* if aarch32 mode is not supported at EL1 do not allow 32-bit domain
> > */
> > -if ( !(cpu_has_el1_32) && kinfo.type == DOMAIN_32BIT )
> > +if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT )
> > {
> > printk("Platform does not support 32-bit domain\n");
> > return -EINVAL;
> > }
> > -d->arch.type = kinfo.type;
> > if ( is_64bit_domain(d) )
> > vcpu_switch_to_aarch64_mode(v);
> > #endif
> > -kinfo.cmdline = kernel != NULL ? >cmdline[0] : NULL;
> > -allocate_memory(d, );
> > -find_gnttab_region(d, );
> > -
> > -/* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
> > -rc = gic_map_hwdom_extra_mappings(d);
> > -if ( rc < 0 )
> > -return rc;
> > -
> > -rc = platform_specific_mapping(d);
> > -if ( rc < 0 )
> > -return rc;
> > -
> > -if ( acpi_disabled )
> > -rc = prepare_dtb(d, );
> > -else
> > -rc = prepare_acpi(d, );
> > -
> > -if ( rc < 0 )
> > -return rc;
> > -
> > /*
> >* The following loads use the domain's p2m and require current to
> >* be a vcpu of the domain, temporarily switch
> > @@ -2187,20 +2143,18 @@ int __init construct_dom0(struct domain *d)
> >* kernel_load will determine the placement of the kernel as well
> >* as the initrd & fdt in RAM, so call it first.
> >*/
> > -kernel_load();
> > +kernel_load(kinfo);
> > /* initrd_load will fix up the fdt, so call it before dtb_load */
> > -initrd_load();
> > -dtb_load();
> > +initrd_load(kinfo);
> > +dtb_load(kinfo);
> > /* Now that we are done restore the original p2m and current. */
> > set_current(saved_current);
> > p2m_restore_state(saved_current);
> > -discard_initial_modules();
> > -
> > memset(regs, 0, sizeof(*regs));
> > -regs->pc = (register_t)kinfo.entry;
> > +regs->pc = (register_t)kinfo->entry;
> > if ( is_32bit_domain(d) )
> > {
> > @@ -2218,14 +2172,14 @@ int __init
Re: [Xen-devel] [PATCH v2 06/12] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create()
On 15/08/18 14:32, Julien Grall wrote:
> Hi Andrew,
#ifdef CONFIG_ARM_32
/*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 45f3841..3d3b30c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -693,6 +694,17 @@ void __init start_xen(unsigned long
boot_phys_offset,
struct domain *dom0;
struct xen_domctl_createdomain dom0_cfg = {
.max_evtchn_port = -1,
+
+ /*
+ * The region used by Xen on the memory will never be mapped
in DOM0
+ * memory layout. Therefore it can be used for the grant
table.
+ *
+ * Only use the text section as it's always present and will
contain
+ * enough space for a large grant table
+ */
+ .max_grant_frames = min_t(unsigned int, opt_max_grant_frames,
+ PFN_DOWN(_etext - _stext)),
>>>
>>> ... not here. So I would prefer if we either keep an helper to find
>>> the size of pass that size around to domain_build. Do we store the
>>> size in the domain information?
>>
>> I have to admit that I'm somewhat perplexed by ARM's
>> find_gnttab_region(), and I'm not sure why it exists.
>
> Dom0 is using the host memory layout that may differ between
> platforms. So there is not a region address that would fit everyone.
>
> This function is here to find at boot a suitable region in the layout
> where the OS can map the grant-table. The result will be written in
> the firmware table.
>
>>
>> The value is available from d->grant_table.max_grant_frames but ISTR
>> finding that the order of construction meant that it wasn't available
>> when needed (although this was all from code inspection, so I could very
>> easily be wrong).
>
> I think it should be fine for Dom0 as find_gnttab_region is called
> from construct_dom0 and d->grant_table.max_grant_frames would be set
> before via domain_create().
>
> Assuming d->grant_table.max_grant_frames can only be 0 before
> initialization, I would potentially add a
> BUG_ON(!d->grant_table.max_grant_frames) to make sure this always stay
> like that.
Actually, I remember now what the problem was. d->grant_table is an
opaque type, so .max_grant_frames can't be accessed.
One of my indented bits of cleanup here is to remove the
gnttab_dom0_frames() function, because it has no business living in the
core grant_table.c
Would you be happy if I replaced gnttab_dom0_max() in asm-arm with
gnttab_dom0_frames() which accounts for the exiting min(), and means
that domain_build.c will be ultimately unchanged?
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 11/15] xen/arm: Allow lpae_is_{table, mapping} helpers to work on invalid entry
On Tue, 14 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 08/14/2018 10:33 PM, Stefano Stabellini wrote:
> > On Mon, 16 Jul 2018, Julien Grall wrote:
> > > Currently, lpae_is_{table, mapping} helpers will always return false on
> > > entry with the valid bit unset. However, it would be useful to have them
> >^entries
> >
> > > operating on any entry. For instance to store information in advance but
> > > still request a fault.
> > >
> > > With that change, the p2m is now providing an overlay for *_is_{table,
> > > mapping} that will check the valid bit of the entry.
> > >
> > > Signed-off-by: Julien Grall
> > >
> > > ---
> > > xen/arch/arm/guest_walk.c | 2 +-
> > > xen/arch/arm/mm.c | 2 +-
> > > xen/arch/arm/p2m.c | 22 ++
> > > xen/include/asm-arm/lpae.h | 11 +++
> > > 4 files changed, 27 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> > > index e3e21bdad3..4a1b4cf2c8 100644
> > > --- a/xen/arch/arm/guest_walk.c
> > > +++ b/xen/arch/arm/guest_walk.c
> > > @@ -566,7 +566,7 @@ static int guest_walk_ld(const struct vcpu *v,
> > >* PTE is invalid or holds a reserved entry (PTE<1:0> == x0)) or if
> > > the PTE
> > >* maps a memory block at level 3 (PTE<1:0> == 01).
> > >*/
> > > -if ( !lpae_is_mapping(pte, level) )
> > > +if ( !lpae_is_valid(pte) || !lpae_is_mapping(pte, level) )
> > > return -EFAULT;
> > > /* Make sure that the lower bits of the PTE's base address are
> > > zero. */
> > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > > index e3dafe5fd7..52e57fef2f 100644
> > > --- a/xen/arch/arm/mm.c
> > > +++ b/xen/arch/arm/mm.c
> > > @@ -996,7 +996,7 @@ static int create_xen_entries(enum xenmap_operation
> > > op,
> > > for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
> > > {
> > > entry = _second[second_linear_offset(addr)];
> > > -if ( !lpae_is_table(*entry, 2) )
> > > +if ( !lpae_is_valid(*entry) || !lpae_is_table(*entry, 2) )
> > > {
> > > rc = create_xen_table(entry);
> > > if ( rc < 0 ) {
> > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > index ec3fdcb554..07925a1be4 100644
> > > --- a/xen/arch/arm/p2m.c
> > > +++ b/xen/arch/arm/p2m.c
> > > @@ -219,6 +219,20 @@ static p2m_access_t p2m_mem_access_radix_get(struct
> > > p2m_domain *p2m, gfn_t gfn)
> > > return radix_tree_ptr_to_int(ptr);
> > > }
> > > +/*
> > > + * lpae_is_* helpers don't check whether the valid bit is set in the
> > > + * PTE. Provide our own overlay to check the valid bit.
> > > + */
> > > +static inline bool p2m_is_mapping(lpae_t pte, unsigned int level)
> > > +{
> > > +return lpae_is_valid(pte) && lpae_is_mapping(pte, level);
> > > +}
> > > +
> > > +static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
> > > +{
> > > +return lpae_is_valid(pte) && lpae_is_superpage(pte, level);
> > > +}
> >
> > I like the idea, but it would be clearer to me if they were called
> > lpae_is_valid_mapping and lpae_is_valid_superpage respectively. What do
> > you think?
> > > Also, we might as well move them to lpae.h and use them from mm.c and
> > guest_walk.c as appropriate?
>
> lpae.h is not suitable because as I said in the commit message each page-table
> (stage-1, stage-2) may have a different view of what "valid" means.
>
> At the moment, that view is the same but it is not going to stay long like
> that. Hence the reason of prefixing with p2m_. They are specific to the p2m.
> This is giving us some more liberty in the future while making the lpae code a
> bit more generic.
>
> In guest_walk.c there are only one user, so the introduction of an helper is
> quite limited there.
I see, so by "p2m_is_mapping" you meant specifically
"stage2_is_mapping", right? That makes sense now.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125923: tolerable all pass - PUSHED
flight 125923 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125923/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-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 version targeted for testing: xen 3dd454c6c694409aaedd4ed075d6aeace2dd8391 baseline version: xen 57c554f8a6e06894f601d977d18b3017d2a60f40 Last test of basis 125920 2018-08-15 13:02:03 Z0 days Testing same since 125923 2018-08-15 16:00:41 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 57c554f8a6..3dd454c6c6 3dd454c6c694409aaedd4ed075d6aeace2dd8391 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-squeeze test] 75071: tolerable FAIL
flight 75071 distros-debian-squeeze real [real] http://osstest.xensource.com/osstest/logs/75071/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 75053 test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 75053 test-amd64-amd64-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 75053 test-amd64-i386-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 75053 baseline version: flight 75053 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-squeeze-netboot-pygrubfail test-amd64-i386-amd64-squeeze-netboot-pygrub fail test-amd64-amd64-i386-squeeze-netboot-pygrub fail test-amd64-i386-i386-squeeze-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/6] x86/mm: Minor non-functional cleanup
Minor cleanup which has accumulated while doing other work. No functional change anywhere. Andrew Cooper (6): x86/mm: Use mfn_eq()/mfn_add() rather than opencoded variations x86/shadow: Use more appropriate conversion functions x86/shadow: Switch shadow_domain.has_fast_mmio_entries to bool x86/shadow: Use MASK_* helpers for the MMIO fastpath PTE manipulation x86/shadow: Clean up the MMIO fastpath helpers x86/shadow: Use mfn_t in shadow_track_dirty_vram() xen/arch/x86/cpu/mcheck/vmce.c | 2 +- xen/arch/x86/domain_page.c | 2 +- xen/arch/x86/mm/hap/hap.c | 3 ++- xen/arch/x86/mm/mem_sharing.c | 4 ++-- xen/arch/x86/mm/p2m-pod.c | 2 +- xen/arch/x86/mm/p2m.c | 4 ++-- xen/arch/x86/mm/shadow/common.c | 44 - xen/arch/x86/mm/shadow/multi.c | 37 +- xen/arch/x86/mm/shadow/types.h | 27 + xen/include/asm-x86/domain.h| 2 +- 10 files changed, 64 insertions(+), 63 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/6] x86/mm: Use mfn_eq()/mfn_add() rather than opencoded variations
Use l1e_get_mfn() in place of l1e_get_pfn() when applicable, and fix up style
on affected lines.
For sh_remove_shadow_via_pointer(), map_domain_page() is guaranteed to succeed
so there is no need to ASSERT() its success. This allows the pointer
arithmetic to folded into the previous expression, and for vaddr to be
properly typed as l1_pgentry_t, avoiding the cast in l1e_get_mfn().
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/cpu/mcheck/vmce.c | 2 +-
xen/arch/x86/domain_page.c | 2 +-
xen/arch/x86/mm/hap/hap.c | 3 ++-
xen/arch/x86/mm/mem_sharing.c | 4 ++--
xen/arch/x86/mm/p2m-pod.c | 2 +-
xen/arch/x86/mm/p2m.c | 4 ++--
xen/arch/x86/mm/shadow/common.c | 34 --
xen/arch/x86/mm/shadow/multi.c | 23 +--
8 files changed, 38 insertions(+), 36 deletions(-)
diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index e07cd2f..ea37006 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -540,7 +540,7 @@ int unmmap_broken_page(struct domain *d, mfn_t mfn,
unsigned long gfn)
r_mfn = get_gfn_query(d, gfn, );
if ( p2m_to_mask(pt) & P2M_UNMAP_TYPES)
{
-ASSERT(mfn_x(r_mfn) == mfn_x(mfn));
+ASSERT(mfn_eq(r_mfn, mfn));
rc = p2m_change_type_one(d, gfn, pt, p2m_ram_broken);
}
put_gfn(d, gfn);
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 0c24530..aee9a80 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -101,7 +101,7 @@ void *map_domain_page(mfn_t mfn)
ASSERT(idx < dcache->entries);
hashent->refcnt++;
ASSERT(hashent->refcnt);
-ASSERT(l1e_get_pfn(MAPCACHE_L1ENT(idx)) == mfn_x(mfn));
+ASSERT(mfn_eq(l1e_get_mfn(MAPCACHE_L1ENT(idx)), mfn));
goto out;
}
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 812a840..d6449e6 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -729,7 +729,8 @@ hap_write_p2m_entry(struct domain *d, unsigned long gfn,
l1_pgentry_t *p,
* unless the only change is an increase in access rights. */
mfn_t omfn = l1e_get_mfn(*p);
mfn_t nmfn = l1e_get_mfn(new);
-flush_nestedp2m = !( mfn_x(omfn) == mfn_x(nmfn)
+
+flush_nestedp2m = !(mfn_eq(omfn, nmfn)
&& perms_strictly_increased(old_flags, l1e_get_flags(new)) );
}
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index fad8a9d..5c08adb 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -500,7 +500,7 @@ static int audit(void)
continue;
}
o_mfn = get_gfn_query_unlocked(d, g->gfn, );
-if ( mfn_x(o_mfn) != mfn_x(mfn) )
+if ( !mfn_eq(o_mfn, mfn) )
{
MEM_SHARING_DEBUG("Incorrect P2M for d=%hu, PFN=%lx."
"Expecting MFN=%lx, got %lx\n",
@@ -904,7 +904,7 @@ static int share_pages(struct domain *sd, gfn_t sgfn,
shr_handle_t sh,
/* This tricky business is to avoid two callers deadlocking if
* grabbing pages in opposite client/source order */
-if( mfn_x(smfn) == mfn_x(cmfn) )
+if ( mfn_eq(smfn, cmfn) )
{
/* The pages are already the same. We could return some
* kind of error here, but no matter how you look at it,
diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 631e9ae..ba37344 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -75,7 +75,7 @@ p2m_pod_cache_add(struct p2m_domain *p2m,
{
struct domain * od;
-p = mfn_to_page(_mfn(mfn_x(mfn) + i));
+p = mfn_to_page(mfn_add(mfn, i));
od = page_get_owner(p);
if ( od != d )
{
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 8e9fbb5..5c73ff8 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1104,7 +1104,7 @@ static int set_typed_p2m_entry(struct domain *d, unsigned
long gfn_l,
for ( i = 0; i < (1UL << order); ++i )
{
-ASSERT(mfn_valid(_mfn(mfn_x(omfn) + i)));
+ASSERT(mfn_valid(mfn_add(omfn, i)));
set_gpfn_from_mfn(mfn_x(omfn) + i, INVALID_M2P_ENTRY);
}
}
@@ -1222,7 +1222,7 @@ int clear_mmio_p2m_entry(struct domain *d, unsigned long
gfn_l, mfn_t mfn,
"gfn_to_mfn failed! gfn=%08lx type:%d\n", gfn_l, t);
goto out;
}
-if ( mfn_x(mfn) != mfn_x(actual_mfn) )
+if ( !mfn_eq(mfn, actual_mfn) )
gdprintk(XENLOG_WARNING,
"no mapping between mfn %08lx and gfn %08lx\n",
mfn_x(mfn), gfn_l);
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index fd42d73..8a7a2b0
[Xen-devel] [PATCH 4/6] x86/shadow: Use MASK_* helpers for the MMIO fastpath PTE manipulation
Drop the now-unused SH_L1E_MMIO_GFN_SHIFT definition.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/mm/shadow/types.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/types.h b/xen/arch/x86/mm/shadow/types.h
index 0430628..8c0c802 100644
--- a/xen/arch/x86/mm/shadow/types.h
+++ b/xen/arch/x86/mm/shadow/types.h
@@ -317,12 +317,11 @@ static inline int sh_l1e_is_gnp(shadow_l1e_t sl1e)
#define SH_L1E_MMIO_MAGIC 0x0001ULL
#define SH_L1E_MMIO_MAGIC_MASK 0x0009ULL
#define SH_L1E_MMIO_GFN_MASK0xfff0ULL
-#define SH_L1E_MMIO_GFN_SHIFT 4
static inline shadow_l1e_t sh_l1e_mmio(gfn_t gfn, u32 gflags)
{
return (shadow_l1e_t) { (SH_L1E_MMIO_MAGIC
- | (gfn_x(gfn) << SH_L1E_MMIO_GFN_SHIFT)
+ | MASK_INSR(gfn_x(gfn), SH_L1E_MMIO_GFN_MASK)
| (gflags & (_PAGE_USER|_PAGE_RW))) };
}
@@ -333,7 +332,7 @@ static inline int sh_l1e_is_mmio(shadow_l1e_t sl1e)
static inline gfn_t sh_l1e_mmio_get_gfn(shadow_l1e_t sl1e)
{
-return _gfn((sl1e.l1 & SH_L1E_MMIO_GFN_MASK) >> SH_L1E_MMIO_GFN_SHIFT);
+return _gfn(MASK_EXTR(sl1e.l1, SH_L1E_MMIO_GFN_MASK));
}
static inline u32 sh_l1e_mmio_get_flags(shadow_l1e_t sl1e)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/6] x86/shadow: Use more appropriate conversion functions
Replace pfn_to_paddr(mfn_x(...)) with mfn_to_maddr(), and replace an opencoded
gfn_to_gaddr().
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/mm/shadow/multi.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 0d74c01..fbdbb7d 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -628,7 +628,7 @@ _sh_propagate(struct vcpu *v,
sflags |= get_pat_flags(v,
gflags,
gfn_to_paddr(target_gfn),
-pfn_to_paddr(mfn_x(target_mfn)),
+mfn_to_maddr(target_mfn),
MTRR_TYPE_UNCACHABLE);
else if ( iommu_snoop )
sflags |= pat_type_2_pte_flags(PAT_TYPE_WRBACK);
@@ -636,7 +636,7 @@ _sh_propagate(struct vcpu *v,
sflags |= get_pat_flags(v,
gflags,
gfn_to_paddr(target_gfn),
-pfn_to_paddr(mfn_x(target_mfn)),
+mfn_to_maddr(target_mfn),
NO_HARDCODE_MEM_TYPE);
}
}
@@ -1131,7 +1131,7 @@ static inline void shadow_vram_get_l1e(shadow_l1e_t
new_sl1e,
if ( (page->u.inuse.type_info & PGT_count_mask) == 1 )
/* Initial guest reference, record it */
-dirty_vram->sl1ma[i] = pfn_to_paddr(mfn_x(sl1mfn))
+dirty_vram->sl1ma[i] = mfn_to_maddr(sl1mfn)
| ((unsigned long)sl1e & ~PAGE_MASK);
}
}
@@ -1160,7 +1160,7 @@ static inline void shadow_vram_put_l1e(shadow_l1e_t
old_sl1e,
unsigned long i = gfn - dirty_vram->begin_pfn;
struct page_info *page = mfn_to_page(mfn);
int dirty = 0;
-paddr_t sl1ma = pfn_to_paddr(mfn_x(sl1mfn))
+paddr_t sl1ma = mfn_to_maddr(sl1mfn)
| ((unsigned long)sl1e & ~PAGE_MASK);
if ( (page->u.inuse.type_info & PGT_count_mask) == 1 )
@@ -2931,8 +2931,7 @@ static int sh_page_fault(struct vcpu *v,
{
/* Magic MMIO marker: extract gfn for MMIO address */
ASSERT(sh_l1e_is_mmio(sl1e));
-gpa = (((paddr_t)(gfn_x(sh_l1e_mmio_get_gfn(sl1e
- << PAGE_SHIFT)
+gpa = gfn_to_gaddr(sh_l1e_mmio_get_gfn(sl1e))
| (va & ~PAGE_MASK);
}
perfc_incr(shadow_fault_fast_mmio);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/6] x86/shadow: Switch shadow_domain.has_fast_mmio_entries to bool
Remove an unecessary if().
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/mm/shadow/common.c | 2 +-
xen/arch/x86/mm/shadow/multi.c | 3 +--
xen/include/asm-x86/domain.h| 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 8a7a2b0..c9640b9 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3687,7 +3687,7 @@ shadow_write_p2m_entry(struct domain *d, unsigned long
gfn,
if ( d->arch.paging.shadow.has_fast_mmio_entries )
{
shadow_blow_tables(d);
-d->arch.paging.shadow.has_fast_mmio_entries = 0;
+d->arch.paging.shadow.has_fast_mmio_entries = false;
}
#endif
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index fbdbb7d..8f90c9f 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -563,8 +563,7 @@ _sh_propagate(struct vcpu *v,
{
/* Guest l1e maps emulated MMIO space */
*sp = sh_l1e_mmio(target_gfn, gflags);
-if ( !d->arch.paging.shadow.has_fast_mmio_entries )
-d->arch.paging.shadow.has_fast_mmio_entries = 1;
+d->arch.paging.shadow.has_fast_mmio_entries = true;
goto done;
}
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 09f6b3d..3da2c68 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -113,7 +113,7 @@ struct shadow_domain {
bool_t hash_walking; /* Some function is walking the hash table */
/* Fast MMIO path heuristic */
-bool_t has_fast_mmio_entries;
+bool has_fast_mmio_entries;
/* OOS */
bool_t oos_active;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 6/6] x86/shadow: Use mfn_t in shadow_track_dirty_vram()
... as the only user of sl1mfn would prefer it that way.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/mm/shadow/common.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index c9640b9..28d1dd4 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3834,7 +3834,7 @@ int shadow_track_dirty_vram(struct domain *d,
memcpy(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_size);
else
{
-unsigned long map_mfn = mfn_x(INVALID_MFN);
+mfn_t map_mfn = INVALID_MFN;
void *map_sl1p = NULL;
/* Iterate over VRAM to track dirty bits. */
@@ -3872,13 +3872,13 @@ int shadow_track_dirty_vram(struct domain *d,
/* Hopefully the most common case: only one mapping,
* whose dirty bit we can use. */
l1_pgentry_t *sl1e;
-unsigned long sl1mfn = paddr_to_pfn(sl1ma);
+mfn_t sl1mfn = maddr_to_mfn(sl1ma);
-if ( sl1mfn != map_mfn )
+if ( !mfn_eq(sl1mfn, map_mfn) )
{
if ( map_sl1p )
unmap_domain_page(map_sl1p);
-map_sl1p = map_domain_page(_mfn(sl1mfn));
+map_sl1p = map_domain_page(sl1mfn);
map_mfn = sl1mfn;
}
sl1e = map_sl1p + (sl1ma & ~PAGE_MASK);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5/6] x86/shadow: Clean up the MMIO fastpath helpers
Use bool when appropraite, remove extranious brackets and fix up comment
style.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/mm/shadow/types.h | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/mm/shadow/types.h b/xen/arch/x86/mm/shadow/types.h
index 8c0c802..d509674 100644
--- a/xen/arch/x86/mm/shadow/types.h
+++ b/xen/arch/x86/mm/shadow/types.h
@@ -294,9 +294,9 @@ void sh_destroy_monitor_table(struct vcpu *v, mfn_t mmfn);
*/
#define SH_L1E_MAGIC 0x0001ULL
-static inline int sh_l1e_is_magic(shadow_l1e_t sl1e)
+static inline bool sh_l1e_is_magic(shadow_l1e_t sl1e)
{
-return ((sl1e.l1 & SH_L1E_MAGIC) == SH_L1E_MAGIC);
+return (sl1e.l1 & SH_L1E_MAGIC) == SH_L1E_MAGIC;
}
/* Guest not present: a single magic value */
@@ -305,15 +305,17 @@ static inline shadow_l1e_t sh_l1e_gnp(void)
return (shadow_l1e_t){ -1ULL };
}
-static inline int sh_l1e_is_gnp(shadow_l1e_t sl1e)
+static inline bool sh_l1e_is_gnp(shadow_l1e_t sl1e)
{
-return (sl1e.l1 == sh_l1e_gnp().l1);
+return sl1e.l1 == sh_l1e_gnp().l1;
}
-/* MMIO: an invalid PTE that contains the GFN of the equivalent guest l1e.
+/*
+ * MMIO: an invalid PTE that contains the GFN of the equivalent guest l1e.
* We store 28 bits of GFN in bits 4:32 of the entry.
* The present bit is set, and the U/S and R/W bits are taken from the guest.
- * Bit 3 is always 0, to differentiate from gnp above. */
+ * Bit 3 is always 0, to differentiate from gnp above.
+ */
#define SH_L1E_MMIO_MAGIC 0x0001ULL
#define SH_L1E_MMIO_MAGIC_MASK 0x0009ULL
#define SH_L1E_MMIO_GFN_MASK0xfff0ULL
@@ -325,9 +327,9 @@ static inline shadow_l1e_t sh_l1e_mmio(gfn_t gfn, u32
gflags)
| (gflags & (_PAGE_USER|_PAGE_RW))) };
}
-static inline int sh_l1e_is_mmio(shadow_l1e_t sl1e)
+static inline bool sh_l1e_is_mmio(shadow_l1e_t sl1e)
{
-return ((sl1e.l1 & SH_L1E_MMIO_MAGIC_MASK) == SH_L1E_MMIO_MAGIC);
+return (sl1e.l1 & SH_L1E_MMIO_MAGIC_MASK) == SH_L1E_MMIO_MAGIC;
}
static inline gfn_t sh_l1e_mmio_get_gfn(shadow_l1e_t sl1e)
@@ -335,9 +337,9 @@ static inline gfn_t sh_l1e_mmio_get_gfn(shadow_l1e_t sl1e)
return _gfn(MASK_EXTR(sl1e.l1, SH_L1E_MMIO_GFN_MASK));
}
-static inline u32 sh_l1e_mmio_get_flags(shadow_l1e_t sl1e)
+static inline uint32_t sh_l1e_mmio_get_flags(shadow_l1e_t sl1e)
{
-return (u32)((sl1e.l1 & (_PAGE_USER|_PAGE_RW)));
+return sl1e.l1 & (_PAGE_USER | _PAGE_RW);
}
#else
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] xen/compiler: introduce a define for weak symbols
On Tue, Jul 24, 2018 at 07:42:21AM -0600, Jan Beulich wrote:
> >>> On 12.07.18 at 09:29, wrote:
> > Forgot to Cc maintainers.
>
> Konrad, Ross: Ping?
Reviewed-by: Konrad Rzeszutek Wilk
Thank you!
>
> Jan
>
> > On Wed, Jul 11, 2018 at 05:34:49PM +0200, Roger Pau Monne wrote:
> >> And replace the open-coded versions already in tree. No functional
> >> change.
> >>
> >> Signed-off-by: Roger Pau Monné
> >> ---
> >> Cc: Jan Beulich
> >> Cc: Andrew Cooper
> >> Cc: Daniel Kiper
> >> ---
> >> xen/include/xen/compiler.h | 2 ++
> >> xen/include/xen/livepatch_payload.h | 4 ++--
> >> 2 files changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
> >> index a7e05681c9..001f589655 100644
> >> --- a/xen/include/xen/compiler.h
> >> +++ b/xen/include/xen/compiler.h
> >> @@ -18,6 +18,8 @@
> >>
> >> #define __packed __attribute__((__packed__))
> >>
> >> +#define __weak__attribute__((weak))
> >> +
> >> #if (!defined(__clang__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 5))
> >> #define unreachable() do {} while (1)
> >> #else
> >> diff --git a/xen/include/xen/livepatch_payload.h
> > b/xen/include/xen/livepatch_payload.h
> >> index 8f38cc2c60..4a1a96d054 100644
> >> --- a/xen/include/xen/livepatch_payload.h
> >> +++ b/xen/include/xen/livepatch_payload.h
> >> @@ -24,7 +24,7 @@ typedef void livepatch_unloadcall_t(void);
> >> * executed in series by the livepatch infrastructure at patch load time.
> >> */
> >> #define LIVEPATCH_LOAD_HOOK(_fn) \
> >> -livepatch_loadcall_t *__attribute__((weak)) \
> >> +livepatch_loadcall_t *__weak \
> >> const livepatch_load_data_##_fn
> >> __section(".livepatch.hooks.load")
> > = _fn;
> >>
> >> /*
> >> @@ -33,7 +33,7 @@ typedef void livepatch_unloadcall_t(void);
> >> * Same as LOAD hook with s/load/unload/
> >> */
> >> #define LIVEPATCH_UNLOAD_HOOK(_fn) \
> >> - livepatch_unloadcall_t *__attribute__((weak)) \
> >> + livepatch_unloadcall_t *__weak \
> >> const livepatch_unload_data_##_fn
> > __section(".livepatch.hooks.unload") = _fn;
> >>
> >> #endif /* __XEN_LIVEPATCH_PAYLOAD_H__ */
> >> --
> >> 2.17.1
> >>
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Armv8-A: Not able to enable secondary CPUs in Hikey960 board
On 08/15/2018 10:15 AM, Omkar Bolla wrote: HI Julien, Hello, As you suggested, I enabled early printk for hikey960 in xen-4.8 stable branch and xen-4.11 stable branch. Looking at the logs, Xen is placed differently in the memory: - Xen 4.8: 0x1aa0 - Xen 4.11: 0x00021fe0 With Xen 4.11, the binary will be placed above 4GB. There was some change in the way to place Xen in the memory in 2016 allowing to place Xen at the end of the usable RAM. I suspect the firmware does not support 64-bit address entry point for secondary CPU. This would explain the ADDRESS_INVALID from PSCI CPU UP call. Can you give a try to this patch: diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 7d40a8466b..13318da6b1 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -408,13 +408,11 @@ static paddr_t __init get_xen_paddr(void) if ( !e ) continue; -#ifdef CONFIG_ARM_32 /* Xen must be under 4GB */ if ( e > 0x1ULL ) e = 0x1ULL; if ( e < bank->start ) continue; -#endif s = e - min_size; Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/build: Use new .nops directive when available
Newer versions of binutils are capable of emitting an exact number bytes worth
of optimised nops, which are P6 nops. Use this in preference to .skip when
available.
Check at boot time whether the toolchain nops are the correct for the running
hardware, andskip optimising nops entirely when possible.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/Rules.mk | 4
xen/arch/x86/alternative.c| 20 +++-
xen/include/asm-x86/alternative-asm.h | 12 +++-
xen/include/asm-x86/alternative.h | 11 +--
4 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index ac585a3..c84ed20 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -29,6 +29,10 @@ $(call as-option-add,CFLAGS,CC,"invpcid
(%rax)$$(comma)%rax",-DHAVE_AS_INVPCID)
$(call as-option-add,CFLAGS,CC,\
".if ((1 > 0) < 0); .error \"\";.endif",,-DHAVE_AS_NEGATIVE_TRUE)
+# Check to see whether the assmbler supports the .nop directive.
+$(call as-option-add,CFLAGS,CC,\
+".L1: .L2: .nops (.L2 - .L1)$$(comma)9",-DHAVE_AS_NOP_DIRECTIVE)
+
CFLAGS += -mno-red-zone -fpic -fno-asynchronous-unwind-tables
# Xen doesn't use SSE interally. If the compiler supports it, also skip the
diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index 0ef7a8b..2c844d6 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -84,6 +84,19 @@ static const unsigned char * const p6_nops[ASM_NOP_MAX+1]
init_or_livepatch_cons
static const unsigned char * const *ideal_nops init_or_livepatch_data =
p6_nops;
+#ifdef HAVE_AS_NOP_DIRECTIVE
+
+/* Nops in .init.rodata to compare against the runtime ideal nops. */
+asm ( ".pushsection .init.rodata, \"a\", @progbits\n\t"
+ "toolchain_nops: .nops " __stringify(ASM_NOP_MAX) "\n\t"
+ ".popsection\n\t");
+extern char toolchain_nops[ASM_NOP_MAX];
+static bool __read_mostly toolchain_nops_are_ideal;
+
+#else
+# define toolchain_nops_are_ideal false
+#endif
+
static void __init arch_init_ideal_nops(void)
{
switch ( boot_cpu_data.x86_vendor )
@@ -112,6 +125,11 @@ static void __init arch_init_ideal_nops(void)
ideal_nops = k8_nops;
break;
}
+
+#ifdef HAVE_AS_NOP_DIRECTIVE
+if ( memcmp(ideal_nops[ASM_NOP_MAX], toolchain_nops, ASM_NOP_MAX) == 0 )
+toolchain_nops_are_ideal = true;
+#endif
}
/* Use this to add nops to a buffer, then text_poke the whole buffer. */
@@ -209,7 +227,7 @@ void init_or_livepatch apply_alternatives(struct alt_instr
*start,
base->priv = 1;
/* Nothing useful to do? */
-if ( a->pad_len <= 1 )
+if ( toolchain_nops_are_ideal || a->pad_len <= 1 )
continue;
add_nops(buf, a->pad_len);
diff --git a/xen/include/asm-x86/alternative-asm.h
b/xen/include/asm-x86/alternative-asm.h
index 0b61516..0d6fb4b 100644
--- a/xen/include/asm-x86/alternative-asm.h
+++ b/xen/include/asm-x86/alternative-asm.h
@@ -1,6 +1,8 @@
#ifndef _ASM_X86_ALTERNATIVE_ASM_H_
#define _ASM_X86_ALTERNATIVE_ASM_H_
+#include
+
#ifdef __ASSEMBLY__
/*
@@ -19,6 +21,14 @@
.byte 0 /* priv */
.endm
+.macro mknops nr_bytes
+#ifdef HAVE_AS_NOP_DIRECTIVE
+.nops \nr_bytes, ASM_NOP_MAX
+#else
+.skip \nr_bytes, 0x90
+#endif
+.endm
+
/* GAS's idea of true is -1, while Clang's idea is 1. */
#ifdef HAVE_AS_NEGATIVE_TRUE
# define as_true(x) (-(x))
@@ -29,7 +39,7 @@
#define decl_orig(insn, padding) \
.L\@_orig_s: insn; .L\@_orig_e: \
.L\@_diff = padding; \
- .skip as_true(.L\@_diff > 0) * .L\@_diff, 0x90; \
+ mknops (as_true(.L\@_diff > 0) * .L\@_diff); \
.L\@_orig_p:
#define orig_len (.L\@_orig_e - .L\@_orig_s)
diff --git a/xen/include/asm-x86/alternative.h
b/xen/include/asm-x86/alternative.h
index 619472e..84b4854 100644
--- a/xen/include/asm-x86/alternative.h
+++ b/xen/include/asm-x86/alternative.h
@@ -2,7 +2,6 @@
#define __X86_ALTERNATIVE_H__
#include
-#include
#ifndef __ASSEMBLY__
#include
@@ -27,6 +26,14 @@ extern void add_nops(void *insns, unsigned int len);
extern void apply_alternatives(struct alt_instr *start, struct alt_instr *end);
extern void alternative_instructions(void);
+asm ( ".macro mknops nr_bytes\n\t"
+#ifdef HAVE_AS_NOP_DIRECTIVE
+ ".nops \\nr_bytes, " __stringify(ASM_NOP_MAX) "\n\t"
+#else
+ ".skip \\nr_bytes, 0x90\n\t"
+#endif
+ ".endm\n\t" );
+
#define alt_orig_len "(.LXEN%=_orig_e - .LXEN%=_orig_s)"
#define alt_pad_len"(.LXEN%=_orig_p - .LXEN%=_orig_e)"
#define alt_total_len "(.LXEN%=_orig_p - .LXEN%=_orig_s)"
@@ -46,7 +53,7 @@ extern void alternative_instructions(void);
#define OLDINSTR(oldinstr, padding) \
".LXEN%=_orig_s:\n\t" oldinstr "\n
Re: [Xen-devel] [PATCH] gnttab/ARM: properly implement gnttab_create_status_page()
On Wed, 15 Aug 2018, Jan Beulich wrote:
> Prevent the "BUG_ON(page_get_owner(pg) != d)" in
> gnttab_unpopulate_status_frames() from triggering.
>
> Reported-by: 王磊
> Signed-off-by: Jan Beulich
>
> ---
> It looks to me as if this was the only piece missing to make v2 grant
> tables work on ARM, but this was build tested only anyway.
For the public records, it cannot be tested until the Linux (or other
OSes functionalities) get implemented. Specifically,
arch_gnttab_map_shared and arch_gnttab_map_status in Linux.
But this patch is a clear improvement on the Xen side:
Reviewed-by: Stefano Stabellini
> --- a/xen/include/asm-arm/grant_table.h
> +++ b/xen/include/asm-arm/grant_table.h
> @@ -21,7 +21,6 @@ int create_grant_host_mapping(unsigned l
> int replace_grant_host_mapping(unsigned long gpaddr, mfn_t mfn,
> unsigned long new_gpaddr, unsigned int flags);
> void gnttab_mark_dirty(struct domain *d, mfn_t mfn);
> -#define gnttab_create_status_page(d, t, i) do {} while (0)
> #define gnttab_release_host_mappings(domain) 1
> static inline int replace_grant_supported(void)
> {
> @@ -84,6 +83,12 @@ static inline unsigned int gnttab_dom0_m
> virt_to_page((char *)(t)->shared_raw[i]), d, SHARE_rw); \
> } while ( 0 )
>
> +#define gnttab_create_status_page(d, t, i) \
> +do { \
> +share_xen_page_with_guest( \
> +virt_to_page((char *)(t)->status[i]), d, SHARE_rw); \
> +} while ( 0 )
> +
> #define gnttab_shared_gmfn(d, t, i) \
> gfn_x(((i) >= nr_grant_frames(t)) ? INVALID_GFN :
> (t)->arch.shared_gfn[i])
>
> ___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 125903: regressions - FAIL
flight 125903 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/125903/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 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-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a version targeted for testing: libvirt b0451117b399df8107340dee8b653cb48e8da1c8 baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 71 days Failing since123840 2018-06-06 04:19:28 Z 70 days 54 attempts Testing same since 125903 2018-08-14 12:01:51 Z1 days1 attempts People who touched revisions under test: Ales Musil Andrea Bolognani Anya Harter Bing Niu Bjoern Walk Bobo Du Boris Fiuczynski Brijesh Singh Changkuo Shi Chen Hanxiao Christian Ehrhardt Clementine Hayat Cole Robinson Daniel Nicoletti Daniel P. Berrangé Daniel Veillard Eric Blake Erik Skultety Fabiano Fidêncio Filip Alac Han Han intrigeri intrigeri Jamie Strandboge Jie Wang Jim Fehlig Jiri Denemark John Ferlan Julio Faracco Ján Tomko Kashyap Chamarthy Katerina Koukiou Laine Stump Laszlo Ersek Luyao Huang Marc Hartmayer Marc Hartmayer Marcos Paulo de Souza Marek Marczykowski-Górecki Martin Kletzander Matthias Bolte Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Pino Toscano Radostin Stoyanov Ramy Elkest ramyelkest Richard W.M. Jones Roman Bogorodskiy Shi Lei Shichangkuo Simon Kobyda Stefan Bader Stefan Berger Sukrit Bhatnagar Tomáš Golembiovský w00251574 Weilun Zhu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-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-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at
[Xen-devel] [PATCH] x86/svm: Fixes to OS Visible Workaround handling
OSVW data is technically per-cpu, but it is the firmwares reponsibility to
make it equivelent on each cpu. A guests OSVW data is sources from global
data in Xen, clearly making it per-domain data rather than per-vcpu data.
Move the data from struct arch_svm_struct to struct svm_domain, and call
svm_guest_osvw_init() from svm_domain_initialise() instead of
svm_vcpu_initialise().
In svm_guest_osvw_init(), reading osvw_length and osvw_status must be done
under the osvw_lock to avoid observing mismatched values. The guests view of
osvw_length also needs clipping at 64 as we only offer one status register (To
date, 5 is the maximum index defined AFAICT). Avoid opencoding max().
Drop svm_handle_osvw() as its shorter and simpler to implement the
functionality inline in svm_msr_{read,write}_intercept(). As the OSVW MSRs
are a contiguous block, we can access them as an array for simplicity.
Signed-off-by: Andrew Cooper
---
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Brian Woods
CC: Jan Beulich
---
xen/arch/x86/hvm/svm/svm.c | 47 +++---
xen/include/asm-x86/hvm/svm/vmcb.h | 14 +++-
2 files changed, 26 insertions(+), 35 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 37f782b..a16f372 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1195,17 +1195,18 @@ void svm_vmenter_helper(const struct cpu_user_regs
*regs)
vmcb->rflags = regs->rflags | X86_EFLAGS_MBS;
}
-static void svm_guest_osvw_init(struct vcpu *vcpu)
+static void svm_guest_osvw_init(struct domain *d)
{
-if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
-return;
+struct svm_domain *svm = >arch.hvm_domain.svm;
+
+spin_lock(_lock);
/*
* Guests should see errata 400 and 415 as fixed (assuming that
* HLT and IO instructions are intercepted).
*/
-vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
-vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
+svm->osvw.length = min(max(3ul, osvw_length), 64ul);
+svm->osvw.status = osvw_status & ~6;
/*
* By increasing VCPU's osvw.length to 3 we are telling the guest that
@@ -1216,7 +1217,9 @@ static void svm_guest_osvw_init(struct vcpu *vcpu)
* is present (because we really don't know).
*/
if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
-vcpu->arch.hvm_svm.osvw.status |= 1;
+svm->osvw.status |= 1;
+
+spin_unlock(_lock);
}
void svm_host_osvw_reset()
@@ -1268,6 +1271,8 @@ static int svm_domain_initialise(struct domain *d)
d->arch.ctxt_switch =
+svm_guest_osvw_init(d);
+
return 0;
}
@@ -1289,8 +1294,6 @@ static int svm_vcpu_initialise(struct vcpu *v)
return rc;
}
-svm_guest_osvw_init(v);
-
return 0;
}
@@ -1627,23 +1630,6 @@ static void svm_init_erratum_383(const struct
cpuinfo_x86 *c)
}
}
-static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, bool_t
read)
-{
-if ( !v->domain->arch.cpuid->extd.osvw )
-return -1;
-
-if ( read )
-{
-if (msr == MSR_AMD_OSVW_ID_LENGTH)
-*val = v->arch.hvm_svm.osvw.length;
-else
-*val = v->arch.hvm_svm.osvw.status;
-}
-/* Writes are ignored */
-
-return 0;
-}
-
static int _svm_cpu_up(bool bsp)
{
uint64_t msr_content;
@@ -1875,6 +1861,7 @@ static int svm_msr_read_intercept(unsigned int msr,
uint64_t *msr_content)
{
int ret;
struct vcpu *v = current;
+const struct domain *d = v->domain;
struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
switch ( msr )
@@ -2017,9 +2004,10 @@ static int svm_msr_read_intercept(unsigned int msr,
uint64_t *msr_content)
case MSR_AMD_OSVW_ID_LENGTH:
case MSR_AMD_OSVW_STATUS:
-ret = svm_handle_osvw(v, msr, msr_content, 1);
-if ( ret < 0 )
+if ( !d->arch.cpuid->extd.osvw )
goto gpf;
+*msr_content =
+d->arch.hvm_domain.svm.osvw.raw[msr - MSR_AMD_OSVW_ID_LENGTH];
break;
default:
@@ -2063,6 +2051,7 @@ static int svm_msr_write_intercept(unsigned int msr,
uint64_t msr_content)
{
int ret, result = X86EMUL_OKAY;
struct vcpu *v = current;
+struct domain *d = v->domain;
struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
switch ( msr )
@@ -2218,9 +2207,9 @@ static int svm_msr_write_intercept(unsigned int msr,
uint64_t msr_content)
case MSR_AMD_OSVW_ID_LENGTH:
case MSR_AMD_OSVW_STATUS:
-ret = svm_handle_osvw(v, msr, _content, 0);
-if ( ret < 0 )
+if ( !d->arch.cpuid->extd.osvw )
goto gpf;
+/* Write-discard */
break;
default:
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h
b/xen/include/asm-x86/hvm/svm/vmcb.h
index 6add818..f7974da 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -493,6 +493,14 @@
[Xen-devel] [PATCH v2] qemu-trad: stop using the default IOREQ server
From: Paul Durrant
Because qemu-trad is using the legacy HVM param mechanism of hooking into
Xen, it means that Xen has to maintain the notion of a 'default' IOREQ
server which is where all I/O goes if no other device model claims it.
Maintaining this code in Xen has a cost and it would be good if the project
no longer had to pay it.
This patch makes the necessary minimal changes to the qemu-trad to use the
IOREQ server API to hook into Xen. This means the default IOREQ server
will no longer be in use and thus it no longer needs to be maintained.
Signed-off-by: Paul Durrant
Acked-by: Andrew Cooper
---
v2: Leave comment about MMCFG/legacy compatibility
---
hw/pci.c| 3 +++
hw/xen_machine_fv.c | 75 +++--
i386-dm/exec-dm.c | 10 ---
i386-dm/helper2.c | 35 +++--
qemu-xen.h | 8 ++
5 files changed, 112 insertions(+), 19 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index c423285..68e5805 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -263,6 +263,8 @@ PCIDevice *pci_register_device(PCIBus *bus, const char
*name,
pci_dev->config_write = config_write;
bus->devices[devfn] = pci_dev;
pci_dev->irq = qemu_allocate_irqs(pci_set_irq, pci_dev, 4);
+
+map_pci_dev(pci_dev->devfn);
return pci_dev;
}
@@ -305,6 +307,7 @@ int pci_unregister_device(PCIDevice *pci_dev)
{
int ret = 0;
+unmap_pci_dev(pci_dev->devfn);
if (pci_dev->unregister)
ret = pci_dev->unregister(pci_dev);
if (ret)
diff --git a/hw/xen_machine_fv.c b/hw/xen_machine_fv.c
index b385d6a..f0989fa 100644
--- a/hw/xen_machine_fv.c
+++ b/hw/xen_machine_fv.c
@@ -30,6 +30,7 @@
#include "qemu-xen.h"
#include "qemu-aio.h"
#include "xen_backend.h"
+#include "pci.h"
#include
#include
@@ -270,6 +271,17 @@ void qemu_invalidate_entry(uint8_t *buffer) {};
#endif /* defined(MAPCACHE) */
+static ioservid_t ioservid;
+
+void xen_enable_io(void)
+{
+xc_hvm_set_ioreq_server_state(xc_handle, domid, ioservid, 1);
+}
+
+void xen_disable_io(void)
+{
+xc_hvm_set_ioreq_server_state(xc_handle, domid, ioservid, 0);
+}
static void xen_init_fv(ram_addr_t ram_size, int vga_ram_size,
const char *boot_device,
@@ -277,7 +289,9 @@ static void xen_init_fv(ram_addr_t ram_size, int
vga_ram_size,
const char *initrd_filename, const char *cpu_model,
const char *direct_pci)
{
-unsigned long ioreq_pfn;
+extern xen_pfn_t ioreq_pfn;
+extern xen_pfn_t bufioreq_pfn;
+extern evtchn_port_t bufioreq_evtchn;
extern void *shared_page;
extern void *buffered_io_page;
#ifdef __ia64__
@@ -295,10 +309,22 @@ static void xen_init_fv(ram_addr_t ram_size, int
vga_ram_size,
}
#endif
-#ifdef CONFIG_STUBDOM /* the hvmop is not supported on older hypervisors */
-xc_set_hvm_param(xc_handle, domid, HVM_PARAM_DM_DOMAIN, DOMID_SELF);
-#endif
-xc_get_hvm_param(xc_handle, domid, HVM_PARAM_IOREQ_PFN, _pfn);
+if (xc_hvm_create_ioreq_server(xc_handle, domid,
+ HVM_IOREQSRV_BUFIOREQ_ATOMIC,
+ )) {
+fprintf(logfile, "failed to create ioreq server: error %d\n",
+errno);
+exit(-1);
+}
+
+if (xc_hvm_get_ioreq_server_info(xc_handle, domid, ioservid,
+ _pfn, _pfn,
+ _evtchn)) {
+fprintf(logfile, "failed to get ioreq server info: error %d\n",
+errno);
+exit(-1);
+}
+
fprintf(logfile, "shared page at pfn %lx\n", ioreq_pfn);
shared_page = xc_map_foreign_range(xc_handle, domid, XC_PAGE_SIZE,
PROT_READ|PROT_WRITE, ioreq_pfn);
@@ -307,15 +333,17 @@ static void xen_init_fv(ram_addr_t ram_size, int
vga_ram_size,
exit(-1);
}
-xc_get_hvm_param(xc_handle, domid, HVM_PARAM_BUFIOREQ_PFN, _pfn);
-fprintf(logfile, "buffered io page at pfn %lx\n", ioreq_pfn);
+fprintf(logfile, "buffered io page at pfn %lx\n", bufioreq_pfn);
buffered_io_page = xc_map_foreign_range(xc_handle, domid, XC_PAGE_SIZE,
-PROT_READ|PROT_WRITE, ioreq_pfn);
+PROT_READ|PROT_WRITE,
+bufioreq_pfn);
if (buffered_io_page == NULL) {
fprintf(logfile, "map buffered IO page returned error %d\n", errno);
exit(-1);
}
+xen_enable_io();
+
#if defined(__ia64__)
xc_get_hvm_param(xc_handle, domid, HVM_PARAM_BUFPIOREQ_PFN, _pfn);
fprintf(logfile, "buffered pio page at pfn %lx\n", ioreq_pfn);
@@ -377,6 +405,37 @@ static void xen_init_fv(ram_addr_t ram_size, int
vga_ram_size,
pc_machine.init(ram_size, vga_ram_size, boot_device,
kernel_filename, kernel_cmdline, initrd_filename,
[Xen-devel] Xen Security Advisory 274 v3 (CVE-2018-14678) - Linux: Uninitialized state in x86 PV failsafe callback path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2018-14678 / XSA-274 version 3 Linux: Uninitialized state in x86 PV failsafe callback path UPDATES IN VERSION 3 Fix spelling in CREDITS. ISSUE DESCRIPTION = Linux has a `failsafe` callback, invoked by Xen under certain conditions. Normally in this failsafe callback, error_entry is paired with error_exit; and error_entry uses %ebx to communicate to error_exit whether to use the user or kernel return path. Unfortunately, on 64-bit PV Xen on x86, error_exit is called without error_entry being called first, leaving %ebx with an invalid value. IMPACT == A rogue user-space program could crash a guest kernel. Privilege escalation cannot be ruled out. VULNERABLE SYSTEMS == Only 64-bit x86 PV Linux systems are vulnerable. All versions of Linux are vulnerable. MITIGATION == Switching to HVM or PVH guests will mitigate this issue. CREDITS === This issue was discovered by M. Vefa Bicakci, and recognized as a security issue by Andy Lutomirski. RESOLUTION == Applying the appropriate attached patch resolves this issue. NB this patch has not been accepted into Linux upstream yet. An updated advisory will be sent if the fix upstreamed looks significantly different. xsa274-linux-4.17.patch Linux 4.17 $ sha256sum xsa274* 0c30cb13d1d573f446c8cb8d4824ffad8ef9149a7589a19ef9bcc83c07bddcf5 xsa274-linux-4.17.patch $ NOTE ON THE LACK OF EMBARGO === The patch for this issue was published on linux-kernel without being first reported to the XenProject Security Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJbdFA5AAoJEIP+FMlX6CvZWQQIAIxMK2w6CsH2aNQRDiDrgcBc 2FkBbroS5I1XHEhWVyO19aPhp1R3mYNU+pTUUFOevQuKvTP0nuZ0csgk5LUj9UP7 EE/3vM3jkAfmIIuXCAegOcznnEl6Wi9aMKGVXcxMkRu9qjKStGr4We5qvmdPncUj DkTdD6VbmM/Q665b0jU4j2aZPDMsH63qrsbz1rsnPAlYUi1R+yKw56Q5UdRJK17j Jc74v+elyqOkFq7QwH1usfnko+DQziLyLqEBQOztTSps2qYM+VwHLAZkhxNyuLsu 2x9/1D8XoZ+BHvVsVe50QmoNcJViMMunnHNhWYHmtXLYFErwUOt48N1vl+3xFpo= =k4Ak -END PGP SIGNATURE- xsa274-linux-4.17.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/spec-ctrl: add support for modifying SSBD VIA LS_CFG MSR
>>> On 09.08.18 at 21:42, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -611,14 +611,9 @@ static void init_amd(struct cpuinfo_x86 *c)
> ssbd_amd_ls_cfg_mask = 1ull << bit;
> }
>
> - if (ssbd_amd_ls_cfg_mask && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
> + if (ssbd_amd_ls_cfg_mask && !rdmsr_safe(MSR_AMD64_LS_CFG, value))
> if (!boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG))
> setup_force_cpu_cap(X86_FEATURE_SSBD_AMD_LS_CFG);
If the inner if() was not to go away altogether in patch 1, please
fold two successive if()-s like these.
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
First of all - I'm not convinced some of the AMD specific code here
wouldn't better live in cpu/amd.c.
> @@ -50,7 +51,16 @@ bool __initdata bsp_delay_spec_ctrl;
> uint8_t __read_mostly default_xen_spec_ctrl;
> uint8_t __read_mostly default_spec_ctrl_flags;
>
> +/* for SSBD support for AMD via LS_CFG */
> +#define SSBD_AMD_MAX_SOCKET 2
> +struct ssbd_amd_ls_cfg_smt_status {
> +spinlock_t lock;
> +uint32_t mask;
> +} __attribute__ ((aligned (64)));
Where's this literal 64 coming from? Do you perhaps mean
SMP_CACHE_BYTES? And if this is really needed (as said before,
I think the array would better be dynamically allocated than having
compile time determined fixed size), then please don't open-code
__aligned().
> +bool __read_mostly ssbd_amd_smt_en = false;
> +bool __read_mostly default_xen_ssbd_amd_ls_cfg_en = false;
> uint64_t __read_mostly ssbd_amd_ls_cfg_mask = 0ull;
> +struct ssbd_amd_ls_cfg_smt_status *ssbd_amd_smt_status[SSBD_AMD_MAX_SOCKET]
> = {NULL};
Several further pointless initializers.
> +static void ssbd_amd_ls_cfg_set_smt(bool enable_ssbd)
> +{
> +uint32_t socket, core, thread;
> +uint64_t enable_mask;
> +uint64_t ls_cfg;
> +struct ssbd_amd_ls_cfg_smt_status *status;
> +const struct cpuinfo_x86 *c = _cpu_data;
> +
> +socket = c->phys_proc_id;
> +core = c->cpu_core_id;
> +thread = c->apicid & (c->x86_num_siblings - 1);
> +status = ssbd_amd_smt_status[socket] + core;
> +enable_mask = (1ull << thread);
> +
> +spin_lock(>lock);
> +
> +if ( enable_ssbd )
> +{
> +if ( !(status->mask & enable_mask) )
So with ->mask being uint32_t, why does enable_mask need to be
uint64_t? Even uint32_t seems way more than needed, but there's
certainly no point going below this. Just that, as expressed before,
you should please use "unsigned int" in favor of uint32_t everywhere,
unless you really need something that's exactly 32-bits wide.
> +{
> +status->mask |= enable_mask;
> +rdmsrl(MSR_AMD64_LS_CFG, ls_cfg);
> +if ( !(ls_cfg & ssbd_amd_ls_cfg_mask) )
> +{
> +ls_cfg |= ssbd_amd_ls_cfg_mask;
> +wrmsrl(MSR_AMD64_LS_CFG, ls_cfg);
> +}
> +}
> +}
> +else
> +{
> +if ( status->mask & enable_mask )
> +{
> +status->mask &= ~enable_mask;
> +rdmsrl(MSR_AMD64_LS_CFG, ls_cfg);
> +if ( (ls_cfg & ssbd_amd_ls_cfg_mask) && (status->mask == 0) )
Please prefer the shorter ! over " == 0".
> +{
> +ls_cfg &= ~ssbd_amd_ls_cfg_mask;
> +wrmsrl(MSR_AMD64_LS_CFG, ls_cfg);
> +}
> +}
> +}
> +
> +spin_unlock(>lock);
> +}
> +
> +void ssbd_amd_ls_cfg_set(bool enable_ssbd)
> +{
> +if ( !ssbd_amd_ls_cfg_mask ||
> + !boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG) ) {
> +dprintk(XENLOG_ERR, "SSBD AMD LS CFG: invalid mask or missing
> feature\n");
If the plan is for the function to also be called at runtime eventually,
this dprintk() needs to go away.
> +return;
> +}
> +
> +if ( ssbd_amd_smt_en )
> +ssbd_amd_ls_cfg_set_smt(enable_ssbd);
> +else
> +ssbd_amd_ls_cfg_set_nonsmt(enable_ssbd);
> +}
> +
> +static int __init ssbd_amd_ls_cfg_init(void)
> +{
> +uint32_t cores_per_socket, threads_per_core;
> +const struct cpuinfo_x86 *c = _cpu_data;
> +uint32_t core, socket;
> +
> +if ( !ssbd_amd_ls_cfg_mask ||
> + !boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG) )
> +goto ssbd_amd_ls_cfg_init_fail;
Why not simply "return"?
> +switch ( c->x86 )
> +{
> +case 0x15:
> +case 0x16:
> +break;
> +
> +case 0x17:
> +cores_per_socket = c->x86_max_cores;
> +threads_per_core = c->x86_num_siblings;
> +
> +if ( threads_per_core > 1 )
> +{
> +ssbd_amd_smt_en = true;
> +for ( socket = 0; socket < SSBD_AMD_MAX_SOCKET; socket++ )
> +{
> +ssbd_amd_smt_status[socket] =
> + (struct ssbd_amd_ls_cfg_smt_status *)
> + xmalloc_array(struct ssbd_amd_ls_cfg_smt_status,
> +cores_per_socket);
Pointless cast.
> +
Re: [Xen-devel] [PATCH] qemu-trad: stop using the default IOREQ server
Andrew Cooper writes ("[PATCH] qemu-trad: stop using the default IOREQ server"):
> Paul is OoO for a while, so replying on his behalf.
Thank you.
> Qemu-trad has no support for MMCFG, which is the memory mapped interface
> which supersedes the more legacy cfc/cf8 handling for PCI config space
> accesses.
>
> Xen's interface passes the requisite information in MMCFG format, which
> is the most efficient way to do it. This piece of (admittedly messy)
> code converts the information to the legacy interface which is the one
> which Qemu understands.
>
> tl;dr, It's messy, but it is correct, and is the best (/only, short of
> implementing MMCFG support in qemu-trad) way of doing it.
Thanks for this excelent explanation. Can you please add it to the
commit message and/or to a comment in the code ? You may then add my
ack. I will then commit the patch :-).
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86/spec-ctrl: add AMD SSBD LS_CFG in init print
>>> On 09.08.18 at 21:42, wrote:
> Edit the initialization code for AMD's SSBD via the LS_CFG MSR and
> enable it to pass the status to the initial spec-ctrl print_details at
> boot.
>
> Signed-off-by: Brian Woods
> ---
Please have a brief revision log here.
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -598,7 +598,7 @@ static void init_amd(struct cpuinfo_x86 *c)
>* If the user has explicitly chosen to disable Memory Disambiguation
>* to mitigiate Speculative Store Bypass, poke the appropriate MSR.
>*/
> - if (opt_ssbd) {
> + if (!ssbd_amd_ls_cfg_mask) {
> int bit = -1;
>
> switch (c->x86) {
> @@ -607,8 +607,15 @@ static void init_amd(struct cpuinfo_x86 *c)
> case 0x17: bit = 10; break;
> }
>
> - if (bit >= 0 && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
> - value |= 1ull << bit;
> + if (bit >= 0)
> + ssbd_amd_ls_cfg_mask = 1ull << bit;
> + }
I think you want to truly restrict this code to only run on the BSP.
Keying it to !ssbd_amd_ls_cfg_mask will lead to it getting re-run
on APs if the BSP didn't set a non-zero value.
> + if (ssbd_amd_ls_cfg_mask && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
> + if (!boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG))
> + setup_force_cpu_cap(X86_FEATURE_SSBD_AMD_LS_CFG);
Why the if()?
> + if (opt_ssbd) {
> + value |= ssbd_amd_ls_cfg_mask;
> wrmsr_safe(MSR_AMD64_LS_CFG, value);
> }
> }
Wouldn't you better set ssbd_amd_ls_cfg_mask to zero again if
the rdmsr_safe() failed (unexpectedly)?
> --- a/xen/arch/x86/spec_ctrl.c
> +++ b/xen/arch/x86/spec_ctrl.c
> @@ -50,6 +50,8 @@ bool __initdata bsp_delay_spec_ctrl;
> uint8_t __read_mostly default_xen_spec_ctrl;
> uint8_t __read_mostly default_spec_ctrl_flags;
>
> +uint64_t __read_mostly ssbd_amd_ls_cfg_mask = 0ull;
I think I had pointed out already that the initializer is pointless.
See the other variables visible in context.
> @@ -210,10 +212,11 @@ static void __init print_details(enum ind_thunk thunk,
> uint64_t caps)
> printk("Speculative mitigation facilities:\n");
>
> /* Hardware features which pertain to speculative mitigations. */
> -printk(" Hardware features:%s%s%s%s%s%s%s%s\n",
> +printk(" Hardware features:%s%s%s%s%s%s%s%s%s\n",
> (_7d0 & cpufeat_mask(X86_FEATURE_IBRSB)) ? " IBRS/IBPB" : "",
> (_7d0 & cpufeat_mask(X86_FEATURE_STIBP)) ? " STIBP" : "",
> (_7d0 & cpufeat_mask(X86_FEATURE_SSBD)) ? " SSBD" : "",
> + boot_cpu_has(X86_FEATURE_SSBD_AMD_LS_CFG)? " SSBD" : "",
I'm still not really happy about the double " SSBD" string literals
(and also the redundant ones further down), but I'll let Andrew
break ties here. I am however sure I had already pointed out
that there's a blank missing ahead of the ? in any event (and
also again further down).
> --- a/xen/include/asm-x86/cpufeatures.h
> +++ b/xen/include/asm-x86/cpufeatures.h
> @@ -32,3 +32,4 @@ XEN_CPUFEATURE(SC_RSB_PV, (FSCAPINTS+0)*32+18) /* RSB
> overwrite needed for
> XEN_CPUFEATURE(SC_RSB_HVM, (FSCAPINTS+0)*32+19) /* RSB overwrite needed
> for HVM */
> XEN_CPUFEATURE(NO_XPTI, (FSCAPINTS+0)*32+20) /* XPTI mitigation not
> in use */
> XEN_CPUFEATURE(SC_MSR_IDLE, (FSCAPINTS+0)*32+21) /* (SC_MSR_PV ||
> SC_MSR_HVM) && default_xen_spec_ctrl */
> +XEN_CPUFEATURE(SSBD_AMD_LS_CFG, (FSCAPINTS+0)*32+22) /* if SSBD support is
> enabled via LS_CGF MSR on AMD hardware */
As also said before - please no synthetic features unless there's
going to be a use for alternatives patching. A simple boolean
variable is quite sufficient for all other cases.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/12] xen/domain: Allocate d->vcpu[] in domain_create()
>>> On 15.08.18 at 16:03, wrote:
> On 15/08/18 14:11, Jan Beulich wrote:
> On 13.08.18 at 12:01, wrote:
>>> @@ -423,6 +436,11 @@ struct domain *domain_create(domid_t domid,
>>>
>>> sched_destroy_domain(d);
>>>
>>> +if ( d->max_vcpus )
>>> +{
>>> +d->max_vcpus = 0;
>>> +XFREE(d->vcpu);
>>> +}
>>> if ( init_status & INIT_arch )
>>> arch_domain_destroy(d);
>> I'm not sure it is a good idea to free the vcpus this early, in particular
>> before arch_domain_destroy().
>
> Actually, this positioning is deliberate, so as not to change the
> current behaviour of arch_domain_destroy().
>
> Before this patch, d-vcpu[] was guaranteed to be NULL in the
> arch_domain_destroy() call, and I don't currently trust it to work
> properly if changed. All of this cleanup logic needs further improvements.
Oh, good point.
>>> --- a/xen/common/domctl.c
>>> +++ b/xen/common/domctl.c
>>> @@ -554,16 +554,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
>>> u_domctl)
>>>
>>> ret = -EINVAL;
>>> if ( (d == current->domain) || /* no domain_pause() */
>>> - (max > domain_max_vcpus(d)) )
>>> + (max != d->max_vcpus) ) /* max_vcpus set up in createdomain
>>> */
>>> break;
>>>
>>> -/* Until Xenoprof can dynamically grow its vcpu-s array... */
>>> -if ( d->xenoprof )
>>> -{
>>> -ret = -EAGAIN;
>>> -break;
>>> -}
>>> -
>>> /* Needed, for example, to ensure writable p.t. state is synced. */
>>> domain_pause(d);
>>>
>>> @@ -581,38 +574,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
>>> u_domctl)
>>> }
>>> }
>>>
>>> -/* We cannot reduce maximum VCPUs. */
>>> -ret = -EINVAL;
>>> -if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
>>> -goto maxvcpu_out;
>>> -
>>> -/*
>>> - * For now don't allow increasing the vcpu count from a non-zero
>>> - * value: This code and all readers of d->vcpu would otherwise need
>>> - * to be converted to use RCU, but at present there's no tools side
>>> - * code path that would issue such a request.
>>> - */
>>> -ret = -EBUSY;
>>> -if ( (d->max_vcpus > 0) && (max > d->max_vcpus) )
>>> -goto maxvcpu_out;
>>> -
>>> ret = -ENOMEM;
>>> online = cpupool_domain_cpumask(d);
>>> -if ( max > d->max_vcpus )
>>> -{
>>> -struct vcpu **vcpus;
>>> -
>>> -BUG_ON(d->vcpu != NULL);
>>> -BUG_ON(d->max_vcpus != 0);
>>> -
>>> -if ( (vcpus = xzalloc_array(struct vcpu *, max)) == NULL )
>>> -goto maxvcpu_out;
>>> -
>>> -/* Install vcpu array /then/ update max_vcpus. */
>>> -d->vcpu = vcpus;
>>> -smp_wmb();
>>> -d->max_vcpus = max;
>>> -}
>>>
>>> for ( i = 0; i < max; i++ )
>>> {
>> With all of this dropped, I think the domctl should be renamed. By
>> dropping its "max" input at the same time, there would then also
>> no longer be a need to check that the value matches what was
>> stored during domain creation.
>
> I'm still looking to eventually delete the hypercall, but we need to be
> able to clean up all domain/vcpu allocations without calling
> complete_domain_destroy, or rearrange the entry logic so
> complete_domain_destroy() can be reused for a domain which isn't
> currently in the domlist.
>
> Unfortunately, I think this is going to be fairly complicated, I think.
Especially when we expect this to take some time, I think it would
be quite helpful for the domctl to actually say what it does until
then, rather than retaining its current (then misleading) name.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] production-config: Temporarily drop arm64
On Aug 15, 2018, at 05:29, Julien Grall wrote: > > Hi, > >> On 08/15/2018 12:25 AM, Rich Persaud wrote: >>> On Aug 14, 2018, at 18:46, Julien Grall wrote: >>> >>> Hi Rich, >>> > On 08/14/2018 11:42 PM, Rich Persaud wrote: > On Aug 13, 2018, at 10:57, Ian Jackson wrote: > > Both our arm64 boxes are out of commission and repairing them is > taking too long. Apologies if this is already documented elsewhere - does OSStest use Qemu for arm64 testing? >>> >>> Osstest does not use QEMU for testing, but I think it would be too slow to >>> have result in timely manner and use x86 resource as well. >> To avoid having zero test coverage for one target architecture, it may be >> acceptable to temporarily reduce test capacity for other target >> architectures. QEMU has the advantage of being faster to "rack" a test >> architecture for temporary use. > > Well, arm64 test coverage was already reduced because we had only 2 platforms > ready for testing. I can hardly imagine how this code be reduced more for > fitting QEMU. Beware that we compile natively in Osstest so this will take an > awful lot of time here. > > However, the main problem here is not the lack of platform but the lack of > time for OSSTest team (mostly Ian and Wei) to investigate and bring-up new > platforms. Maybe you can help finding contributors to help on Arm64? This may happen via testing of the OpenEmbedded meta-virtualization layer support for Xen, where OE enables cross-compilation. Rich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-4.9-testing test] 125901: regressions - trouble: blocked/broken/fail/pass
flight 125901 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/125901/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt broken build-arm64-xsm broken in 125876 build-arm64-pvopsbroken in 125876 build-arm64 broken in 125876 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 124328 build-armhf-libvirt 5 host-build-prep fail REGR. vs. 124328 build-i386-pvops 6 kernel-build fail REGR. vs. 124328 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 125876 test-amd64-amd64-xl-rtds 10 debian-install fail pass in 125876 Regressions which are regarded as allowable (not blocking): build-arm64-xsm 2 hosts-allocate broken in 125876 REGR. vs. 124328 build-arm64-pvops 2 hosts-allocate broken in 125876 REGR. vs. 124328 build-arm64 2 hosts-allocate broken in 125876 REGR. vs. 124328 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 125876 n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked in 125876 n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked in 125876 n/a test-arm64-arm64-xl 1 build-check(1) blocked in 125876 n/a build-arm64-libvirt 1 build-check(1) blocked in 125876 n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 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-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 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-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a build-arm64-xsm 3 capture-logs broken in 125876 blocked in 124328 build-arm64-pvops3 capture-logs broken in 125876 blocked in 124328 build-arm64 3 capture-logs broken in 125876 blocked in 124328 test-armhf-armhf-xl-rtds 17 guest-start.2 fail blocked in 124328 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail blocked in 124328 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 125876 blocked in 124328 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 125876 blocked in 124328 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail in 125876 like 124248 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigrate
[Xen-devel] [xen-unstable-smoke test] 125920: tolerable all pass - PUSHED
flight 125920 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125920/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-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 version targeted for testing: xen 57c554f8a6e06894f601d977d18b3017d2a60f40 baseline version: xen 80cdb33cb7a96c3355b35ec620f1798fe3be1048 Last test of basis 125918 2018-08-15 10:00:26 Z0 days Testing same since 125920 2018-08-15 13:02:03 Z0 days1 attempts People who touched revisions under test: Jan Beulich Paul Durrant jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 80cdb33cb7..57c554f8a6 57c554f8a6e06894f601d977d18b3017d2a60f40 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] L1TF, and future work
On 15/08/18 16:10, Jan Beulich wrote:
On 15.08.18 at 15:17, wrote:
>> 2) 32bit PV guests which use writeable pagetable support will
>> automatically get shadowed when the clear the lower half.
>
> ... of a page table entry.
>
>> Ideally, such
>> guests should be modified to use hypercalls rather than the ptwr
>> infrastructure (as its more efficient to begin with), but we can
>> probably work around this in Xen by emulating the next few instructions
>> until we have a complete PTE (same as the shadow code).
>
> Provided the intervening insns are simple enough. I've looked into
> current Linux pv-ops code the other day, and afaict it's already
> using mmu-op or cmpxchg8b, but not two separate mov-s. But
> of course I've looked at the general routines only, not at things
> perhaps hidden in special cases, or in init-only code.
Look at xen_pte_clear(). Inside irq handling it will use (PAE case):
static inline void native_pte_clear(struct mm_struct *mm, unsigned long
addr,
pte_t *ptep)
{
ptep->pte_low = 0;
smp_wmb();
ptep->pte_high = 0;
}
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] L1TF, and future work
>>> On 15.08.18 at 15:17, wrote: > 2) 32bit PV guests which use writeable pagetable support will > automatically get shadowed when the clear the lower half. ... of a page table entry. > Ideally, such > guests should be modified to use hypercalls rather than the ptwr > infrastructure (as its more efficient to begin with), but we can > probably work around this in Xen by emulating the next few instructions > until we have a complete PTE (same as the shadow code). Provided the intervening insns are simple enough. I've looked into current Linux pv-ops code the other day, and afaict it's already using mmu-op or cmpxchg8b, but not two separate mov-s. But of course I've looked at the general routines only, not at things perhaps hidden in special cases, or in init-only code. > 4) The shadow MMIO fastpath truncates the MMIO gfn at 2^28 without any > indication of failure. The most compatible bugfix AFACIT would be to > add an extra nibble's worth of gfn space which gets us to 2^32, and > clamp the guest maxphysaddr calculation at 44 bits. The alternative is > to clamp maxphysaddr to 40 bits, but that will break incoming migrate of > very large shadow guests. Urgh. > 4a) The shadow MMIO fastpath needs a runtime clobber, because it will > not function at all on Icelake hardware with a 52-bit physical address > width. Also, it turns out there is an architectural corner case when > levelling maxphysaddr, where some bits which (v)maxphysaddr says should > elicit #PF[RSVD], don't because the actual pipeline address width is larger. By "runtime clobber" you mean something to disable that path at runtime, rather than at build time? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] L1TF, and future work
On 15/08/18 15:21, Andrew Cooper wrote: > On 15/08/18 14:17, Andrew Cooper wrote: >> Hello, > > Apologies. Getting Dario's correct email address this time. > >> >> Now that the embargo on XSA-273 is up, we can start publicly discussing >> the remaining work do, because there is plenty to do. In no particular >> order... >> >> 1) Attempting to shadow dom0 from boot leads to some assertions very >> very quickly. Shadowing dom0 after-the-fact leads to some very weird >> crashes where whole swathes of the shadow appears to be missing. This >> is why, for now, automatic shadowing of dom0 is disabled by default. >> >> 2) 32bit PV guests which use writeable pagetable support will >> automatically get shadowed when the clear the lower half. Ideally, such >> guests should be modified to use hypercalls rather than the ptwr >> infrastructure (as its more efficient to begin with), but we can >> probably work around this in Xen by emulating the next few instructions >> until we have a complete PTE (same as the shadow code). I can work on that in the Linux kernel. There has been another bug which I suspect is related to that: https://bugzilla.kernel.org/show_bug.cgi?id=198497 Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/12] xen/domain: Allocate d->vcpu[] in domain_create()
On 15/08/18 14:11, Jan Beulich wrote:
On 13.08.18 at 12:01, wrote:
>> @@ -423,6 +436,11 @@ struct domain *domain_create(domid_t domid,
>>
>> sched_destroy_domain(d);
>>
>> +if ( d->max_vcpus )
>> +{
>> +d->max_vcpus = 0;
>> +XFREE(d->vcpu);
>> +}
>> if ( init_status & INIT_arch )
>> arch_domain_destroy(d);
> I'm not sure it is a good idea to free the vcpus this early, in particular
> before arch_domain_destroy().
Actually, this positioning is deliberate, so as not to change the
current behaviour of arch_domain_destroy().
Before this patch, d-vcpu[] was guaranteed to be NULL in the
arch_domain_destroy() call, and I don't currently trust it to work
properly if changed. All of this cleanup logic needs further improvements.
>
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -554,16 +554,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
>> u_domctl)
>>
>> ret = -EINVAL;
>> if ( (d == current->domain) || /* no domain_pause() */
>> - (max > domain_max_vcpus(d)) )
>> + (max != d->max_vcpus) ) /* max_vcpus set up in createdomain
>> */
>> break;
>>
>> -/* Until Xenoprof can dynamically grow its vcpu-s array... */
>> -if ( d->xenoprof )
>> -{
>> -ret = -EAGAIN;
>> -break;
>> -}
>> -
>> /* Needed, for example, to ensure writable p.t. state is synced. */
>> domain_pause(d);
>>
>> @@ -581,38 +574,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
>> u_domctl)
>> }
>> }
>>
>> -/* We cannot reduce maximum VCPUs. */
>> -ret = -EINVAL;
>> -if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
>> -goto maxvcpu_out;
>> -
>> -/*
>> - * For now don't allow increasing the vcpu count from a non-zero
>> - * value: This code and all readers of d->vcpu would otherwise need
>> - * to be converted to use RCU, but at present there's no tools side
>> - * code path that would issue such a request.
>> - */
>> -ret = -EBUSY;
>> -if ( (d->max_vcpus > 0) && (max > d->max_vcpus) )
>> -goto maxvcpu_out;
>> -
>> ret = -ENOMEM;
>> online = cpupool_domain_cpumask(d);
>> -if ( max > d->max_vcpus )
>> -{
>> -struct vcpu **vcpus;
>> -
>> -BUG_ON(d->vcpu != NULL);
>> -BUG_ON(d->max_vcpus != 0);
>> -
>> -if ( (vcpus = xzalloc_array(struct vcpu *, max)) == NULL )
>> -goto maxvcpu_out;
>> -
>> -/* Install vcpu array /then/ update max_vcpus. */
>> -d->vcpu = vcpus;
>> -smp_wmb();
>> -d->max_vcpus = max;
>> -}
>>
>> for ( i = 0; i < max; i++ )
>> {
> With all of this dropped, I think the domctl should be renamed. By
> dropping its "max" input at the same time, there would then also
> no longer be a need to check that the value matches what was
> stored during domain creation.
I'm still looking to eventually delete the hypercall, but we need to be
able to clean up all domain/vcpu allocations without calling
complete_domain_destroy, or rearrange the entry logic so
complete_domain_destroy() can be reused for a domain which isn't
currently in the domlist.
Unfortunately, I think this is going to be fairly complicated, I think.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/12] xen/domain: Allocate d->vcpu[] in domain_create()
On 15/08/18 14:52, Julien Grall wrote:
> Hi Andrew,
>
> On 08/15/2018 02:50 PM, Andrew Cooper wrote:
>> On 15/08/18 14:17, Julien Grall wrote:
> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
> index 832632a..4124817 100644
> --- a/xen/arch/arm/vgic/vgic.c
> +++ b/xen/arch/arm/vgic/vgic.c
> @@ -951,27 +951,7 @@ void vgic_sync_hardware_irq(struct domain *d,
> unsigned int vgic_max_vcpus(const struct domain *d)
> {
> - unsigned int vgic_vcpu_limit;
> -
> - switch ( d->arch.vgic.version )
> - {
> - case GIC_INVALID:
> - /*
> - * Since evtchn_init would call domain_max_vcpus for
> poll_mask
> - * allocation before the VGIC has been initialised, we
> need to
> - * return some safe value in this case. As this is for
> allocation
> - * purposes, go with the maximum value.
> - */
> - vgic_vcpu_limit = MAX_VIRT_CPUS;
> - break;
> - case GIC_V2:
> - vgic_vcpu_limit = VGIC_V2_MAX_CPUS;
> - break;
> - default:
> - BUG();
> - }
> -
> - return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
> + return min_t(unsigned int, MAX_VIRT_CPUS,
> d->arch.vgic.handler->max_vcpus);
> }
Since both implementations are equal now, can you place this in vgic.h
as a static inline function?
>>>
>>> vgic/vgic.c is part of the new vGIC implementation (selectable at th e
>>> compilation time) and using a different layout for the vgic_dist
>>> structure. The structure is described in asm/new_vgic.h and does not
>>> store the max vcpus anymore.
>>>
>>> Instead, the switch should be retained and only the case GIC_INVALID
>>> should be dropped.
>>
>> What about GIC_V3? VGIC_V3_MAX_CPUS seems to be 255 at the moment.
>
> GICv3 is not yet supported by the new vGIC and disabled at compile
> time. So we should never reach this code with d->arch.vgic.version ==
> GIC_V3.
Ok - no problem. I'll refresh this to just deleting the INVALID case.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/12] xen/domain: Allocate d->vcpu[] in domain_create()
Hi Andrew,
On 08/15/2018 02:50 PM, Andrew Cooper wrote:
On 15/08/18 14:17, Julien Grall wrote:
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 832632a..4124817 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -951,27 +951,7 @@ void vgic_sync_hardware_irq(struct domain *d,
unsigned int vgic_max_vcpus(const struct domain *d)
{
- unsigned int vgic_vcpu_limit;
-
- switch ( d->arch.vgic.version )
- {
- case GIC_INVALID:
- /*
- * Since evtchn_init would call domain_max_vcpus for poll_mask
- * allocation before the VGIC has been initialised, we need to
- * return some safe value in this case. As this is for
allocation
- * purposes, go with the maximum value.
- */
- vgic_vcpu_limit = MAX_VIRT_CPUS;
- break;
- case GIC_V2:
- vgic_vcpu_limit = VGIC_V2_MAX_CPUS;
- break;
- default:
- BUG();
- }
-
- return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
+ return min_t(unsigned int, MAX_VIRT_CPUS,
d->arch.vgic.handler->max_vcpus);
}
Since both implementations are equal now, can you place this in vgic.h
as a static inline function?
vgic/vgic.c is part of the new vGIC implementation (selectable at th e
compilation time) and using a different layout for the vgic_dist
structure. The structure is described in asm/new_vgic.h and does not
store the max vcpus anymore.
Instead, the switch should be retained and only the case GIC_INVALID
should be dropped.
What about GIC_V3? VGIC_V3_MAX_CPUS seems to be 255 at the moment.
GICv3 is not yet supported by the new vGIC and disabled at compile time.
So we should never reach this code with d->arch.vgic.version == GIC_V3.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/12] xen/domain: Allocate d->vcpu[] in domain_create()
On 15/08/18 14:17, Julien Grall wrote:
>>> diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
>>> index 832632a..4124817 100644
>>> --- a/xen/arch/arm/vgic/vgic.c
>>> +++ b/xen/arch/arm/vgic/vgic.c
>>> @@ -951,27 +951,7 @@ void vgic_sync_hardware_irq(struct domain *d,
>>> unsigned int vgic_max_vcpus(const struct domain *d)
>>> {
>>> - unsigned int vgic_vcpu_limit;
>>> -
>>> - switch ( d->arch.vgic.version )
>>> - {
>>> - case GIC_INVALID:
>>> - /*
>>> - * Since evtchn_init would call domain_max_vcpus for poll_mask
>>> - * allocation before the VGIC has been initialised, we need to
>>> - * return some safe value in this case. As this is for
>>> allocation
>>> - * purposes, go with the maximum value.
>>> - */
>>> - vgic_vcpu_limit = MAX_VIRT_CPUS;
>>> - break;
>>> - case GIC_V2:
>>> - vgic_vcpu_limit = VGIC_V2_MAX_CPUS;
>>> - break;
>>> - default:
>>> - BUG();
>>> - }
>>> -
>>> - return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
>>> + return min_t(unsigned int, MAX_VIRT_CPUS,
>>> d->arch.vgic.handler->max_vcpus);
>>> }
>>
>> Since both implementations are equal now, can you place this in vgic.h
>> as a static inline function?
>
> vgic/vgic.c is part of the new vGIC implementation (selectable at th e
> compilation time) and using a different layout for the vgic_dist
> structure. The structure is described in asm/new_vgic.h and does not
> store the max vcpus anymore.
>
> Instead, the switch should be retained and only the case GIC_INVALID
> should be dropped.
What about GIC_V3? VGIC_V3_MAX_CPUS seems to be 255 at the moment.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v16 12/13] x86/hvm: Remove redundant save functions
>>> On 09.08.18 at 11:21, wrote:
> @@ -148,6 +145,11 @@ int hvm_save_one(struct domain *d, unsigned int
> typecode, unsigned int instance,
> !hvm_sr_handlers[typecode].save )
> return -EINVAL;
>
> +if ( hvm_sr_handlers[typecode].kind == HVMSR_PER_VCPU &&
> +instance >= d->max_vcpus )
> +return -ENOENT;
> +if ( hvm_sr_handlers[typecode].kind == HVMSR_PER_DOM )
> +instance = 0;
How can you validly override what the caller has requested? There's a
use further down in the function (" if ( instance == desc->instance )")
which you break with the above. As said at least once before - we
have an example of a two-instance per-domain save record, and you
should keep that code functioning even if there's currently no in-tree
caller.
Also when checking a field (here: .kind) like this, please use a
switch() statement. But perhaps here if/else would suffice to avoid
the redundant field reference.
> @@ -223,17 +225,29 @@ int hvm_save(struct domain *d, hvm_domain_context_t *h)
> for ( i = 0; i <= HVM_SAVE_CODE_MAX; i++ )
> {
> struct vcpu *v;
> -hvm_save_vcpu_handler save_one_handler = hvm_sr_handlers[i].save_one;
> -hvm_save_handler handler = hvm_sr_handlers[i].save;;
> +hvm_save_handler handler = hvm_sr_handlers[i].save;
>
> -if ( save_one_handler )
> +if ( handler )
> {
> -for_each_vcpu ( d, v )
> +if ( hvm_sr_handlers[i].kind == HVMSR_PER_VCPU )
> {
> -printk(XENLOG_G_INFO "HVM %pv save: %s\n",
> - v, hvm_sr_handlers[i].name);
> -
> -if ( save_one_handler(v, h) != 0 )
> +for_each_vcpu ( d, v )
Please avoid re-indenting all of this code, by simply inverting the outer
if() to
if ( !handler )
continue;
For reviewers this will also make more obvious what the actual
changes are.
> +{
> +printk(XENLOG_G_INFO "HVM %pv save: %s\n",
> + v, hvm_sr_handlers[i].name);
> +
> +if ( handler(v, h) != 0 )
> +{
> +printk(XENLOG_G_ERR
> + "HVM %pv save: failed to save type
> %"PRIu16"\n",
> + v, i);
> +return -ENODATA;
> +}
> +}
> +}
> +else
> +{
> +if ( handler(v, h) != 0 )
I can't seem to be able to spot where v would get set before the use
here. Did you test your code, making sure that migration still works?
Also note how this could easily be "else if ()".
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 06/12] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create()
Hi Andrew,
On 08/15/2018 02:08 PM, Andrew Cooper wrote:
On 15/08/18 14:04, Julien Grall wrote:
Hi Andrew,
On 08/13/2018 11:01 AM, Andrew Cooper wrote:
... rather than setting the limits up after domain_create() has
completed.
This removes all the gnttab infrastructure for calculating the number
of dom0
grant frames, opting instead to require the dom0 construction code to
pass a
sane value in via the configuration.
In practice, this now means that there is never a partially
constructed grant
table for a reference-able domain.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Wei Liu
v2:
* Split/rearrange to avoid the post-domain-create error path.
---
xen/arch/arm/domain_build.c | 3 ++-
xen/arch/arm/setup.c | 12
xen/arch/x86/setup.c | 3 +++
xen/common/domain.c | 3 ++-
xen/common/grant_table.c | 16 +++-
xen/include/asm-arm/grant_table.h | 12
xen/include/asm-x86/grant_table.h | 5 -
xen/include/xen/grant_table.h | 6 ++
8 files changed, 24 insertions(+), 36 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1351572..737e0f3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2079,7 +2079,8 @@ static void __init find_gnttab_region(struct
domain *d,
* enough space for a large grant table
*/
kinfo->gnttab_start = __pa(_stext);
- kinfo->gnttab_size = gnttab_dom0_frames() << PAGE_SHIFT;
+ kinfo->gnttab_size = min_t(unsigned int, opt_max_grant_frames,
+ PFN_DOWN(_etext - _stext)) <<
PAGE_SHIFT;
I agree with Jan's comment on v1 that there is a risk someone will
update the size here but ...
#ifdef CONFIG_ARM_32
/*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 45f3841..3d3b30c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -693,6 +694,17 @@ void __init start_xen(unsigned long
boot_phys_offset,
struct domain *dom0;
struct xen_domctl_createdomain dom0_cfg = {
.max_evtchn_port = -1,
+
+ /*
+ * The region used by Xen on the memory will never be mapped
in DOM0
+ * memory layout. Therefore it can be used for the grant table.
+ *
+ * Only use the text section as it's always present and will
contain
+ * enough space for a large grant table
+ */
+ .max_grant_frames = min_t(unsigned int, opt_max_grant_frames,
+ PFN_DOWN(_etext - _stext)),
... not here. So I would prefer if we either keep an helper to find
the size of pass that size around to domain_build. Do we store the
size in the domain information?
I have to admit that I'm somewhat perplexed by ARM's
find_gnttab_region(), and I'm not sure why it exists.
Dom0 is using the host memory layout that may differ between platforms.
So there is not a region address that would fit everyone.
This function is here to find at boot a suitable region in the layout
where the OS can map the grant-table. The result will be written in the
firmware table.
The value is available from d->grant_table.max_grant_frames but ISTR
finding that the order of construction meant that it wasn't available
when needed (although this was all from code inspection, so I could very
easily be wrong).
I think it should be fine for Dom0 as find_gnttab_region is called from
construct_dom0 and d->grant_table.max_grant_frames would be set before
via domain_create().
Assuming d->grant_table.max_grant_frames can only be 0 before
initialization, I would potentially add a
BUG_ON(!d->grant_table.max_grant_frames) to make sure this always stay
like that.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v16 09/13] x86/hvm: Introduce lapic_save_regs_one func
>>> On 09.08.18 at 11:20, wrote:
> This is used to save data from a single instance.
>
> Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
albeit I'm a little puzzled why ...
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1458,26 +1458,33 @@ static int lapic_save_hidden(struct domain *d,
> hvm_domain_context_t *h)
> return err;
> }
>
> +static int lapic_save_regs_one(struct vcpu *v, hvm_domain_context_t *h)
> +{
> +if ( !has_vlapic(v->domain) )
> +return 0;
> +
> +if ( hvm_funcs.sync_pir_to_irr )
> +hvm_funcs.sync_pir_to_irr(v);
> +
> +return hvm_save_entry(LAPIC_REGS, v->vcpu_id, h, vcpu_vlapic(v)->regs);
> +}
> +
> static int lapic_save_regs(struct domain *d, hvm_domain_context_t *h)
> {
> struct vcpu *v;
> -struct vlapic *s;
> -int rc = 0;
> +int err = 0;
>
> if ( !has_vlapic(d) )
> return 0;
... you leave this here when in patch 8 you've dropped the
equivalent there. But the function as a whole will go away anyway.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RESEND] compat-ioctl/Xen: support at least some IOCTLs of evtchn and privcmd
On Wed, Aug 15, 2018 at 07:16:43AM -0600, Jan Beulich wrote: > >>> On 15.08.18 at 14:51, wrote: > > On Wed, Aug 15, 2018 at 12:19:00AM -0600, Jan Beulich wrote: > >> While this is only a start (IOCTL_PRIVCMD_MMAP* and IOCTL_PRIVCMD_DM_OP > >> require more work), it at least allows some simple operations (like > >> "xl dmesg") which have always been available on XenoLinux to work again > >> with a 64-bit kernel underneath a 32-bit distro. > >> > >> Signed-off-by: Jan Beulich > >> Acked-by: Juergen Gross > > > > > > Nacked-by: Al Viro > > > > This belongs in drivers/xen/privcmd.c, not in fs/compat_ioctl.c > > *ANY* single-driver ioctl definitely should be handled by ->compat_ioctl() > > method and any patches dumping such stuff into fs/compat_ioctl.c will be > > rejected. > > Okay, I'll see about doing this; I have to admit I was unaware of > ->compat_ioctl()'s existence. It would be rather helpful if the header > of compat_ioctl.c indicated what you say. Without that, I've simply > gone by the observation that there are things in the file which > according to what you say shouldn't be there, and I've then wrongly > implied adding the Xen stuff here would be fine. Originally fs/compat_ioctl.c was a result of merger between several such beasts in arch/*; it's *old* - well before ->compat_ioctl() introduction. If you check the history of that thing, you'll see crap getting removed over the years. Sometimes the things sneak in, but generally it keeps shrinking... The only stuff that might belong there is widely-implemented ioctls. Anything that is natively handled in a couple of ->ioctl() instances should be getting ->compat_ioctl() instance to go with that one. And yes, big fat warning along the lines of "don't dump here" is probably a good idea... ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] qemu-trad: stop using the default IOREQ server
On 15/08/18 12:00, Ian Jackson wrote:
> Paul Durrant writes ("[PATCH] qemu-trad: stop using the default IOREQ
> server"):
>> Because qemu-trad is using the legacy HVM param mechanism of hooking into
>> Xen, it means that Xen has to maintain the notion of a 'default' IOREQ
>> server which is where all I/O goes if no other device model claims it.
>> Maintaining this code in Xen has a cost and it would be good if the project
>> no longer had to pay it.
>>
>> This patch makes the necessary minimal changes to the qemu-trad to use the
>> IOREQ server API to hook into Xen. This means the default IOREQ server
>> will no longer be in use and thus it no longer needs to be maintained.
> That is a good thing.
>
> I looked overr the patch. Most of it is about what I would have
> expected.
>
> But I did want to query this:
>
>> +case IOREQ_TYPE_PCI_CONFIG: {
>> +uint32_t sbdf = req->addr >> 32;
>> +uint32_t val;
>> +
>> +/* Fake out to 0xcf8 */
>> +val = (1u << 31) |
>> +((req->addr & 0x0f00) << 16) |
>> +((sbdf & 0x) << 8) |
>> +(req->addr & 0xfc);
>> +do_outp(env, 0xcf8, 4, val);
>> +
>> +/* Now fake I/O to 0xcfc */
>> +req->addr = 0xcfc | (req->addr & 0x03);
>> +cpu_ioreq_pio(env, req);
>> +break;
>> +}
> This looks messy. Can someone please explain why this is needed and
> why it is best to do it this way ?
>
> (I'm don't know much about PCI, which is probably a contributory
> factor in my querying this. Sorry about that.)
Paul is OoO for a while, so replying on his behalf.
Qemu-trad has no support for MMCFG, which is the memory mapped interface
which supersedes the more legacy cfc/cf8 handling for PCI config space
accesses.
Xen's interface passes the requisite information in MMCFG format, which
is the most efficient way to do it. This piece of (admittedly messy)
code converts the information to the legacy interface which is the one
which Qemu understands.
tl;dr, It's messy, but it is correct, and is the best (/only, short of
implementing MMCFG support in qemu-trad) way of doing it.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v16 08/13] x86/hvm: Introduce lapic_save_hidden_one
>>> On 09.08.18 at 11:20, wrote: > This is used to save data from a single instance. > > Signed-off-by: Alexandru Isaila Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v16 06/13] x86/hvm: Introduce hvm_save_mtrr_msr_one func
>>> On 09.08.18 at 11:20, wrote:
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -718,52 +718,56 @@ int hvm_set_mem_pinned_cacheattr(struct domain *d,
> uint64_t gfn_start,
> return 0;
> }
>
> -static int hvm_save_mtrr_msr(struct domain *d, hvm_domain_context_t *h)
> +static int hvm_save_mtrr_msr_one(struct vcpu *v, hvm_domain_context_t *h)
> {
> -struct vcpu *v;
> +const struct mtrr_state *mtrr_state = >arch.hvm_vcpu.mtrr;
> +struct hvm_hw_mtrr hw_mtrr = {
> +.msr_mtrr_def_type = mtrr_state->def_type |
> + MASK_INSR(mtrr_state->fixed_enabled,
> + MTRRdefType_FE) |
> + MASK_INSR(mtrr_state->enabled, MTRRdefType_E),
> +.msr_mtrr_cap = mtrr_state->mtrr_cap,
> +};
> +unsigned int i;
>
> -/* save mtrr */
> -for_each_vcpu(d, v)
> +if ( MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT) >
> + (ARRAY_SIZE(hw_mtrr.msr_mtrr_var) / 2) )
> {
> -const struct mtrr_state *mtrr_state = >arch.hvm_vcpu.mtrr;
> -struct hvm_hw_mtrr hw_mtrr = {
> -.msr_mtrr_def_type = mtrr_state->def_type |
> - MASK_INSR(mtrr_state->fixed_enabled,
> - MTRRdefType_FE) |
> - MASK_INSR(mtrr_state->enabled,
> MTRRdefType_E),
> -.msr_mtrr_cap = mtrr_state->mtrr_cap,
> -};
> -unsigned int i;
> +dprintk(XENLOG_G_ERR,
> +"HVM save: %pv: too many (%lu) variable range MTRRs\n",
> +v, MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT));
> +return -EINVAL;
> +}
>
> -if ( MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT) >
> - (ARRAY_SIZE(hw_mtrr.msr_mtrr_var) / 2) )
> -{
> -dprintk(XENLOG_G_ERR,
> -"HVM save: %pv: too many (%lu) variable range MTRRs\n",
> -v, MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT));
> -return -EINVAL;
> -}
> +hvm_get_guest_pat(v, _mtrr.msr_pat_cr);
>
> -hvm_get_guest_pat(v, _mtrr.msr_pat_cr);
> +for ( i = 0; i < MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT); i++ )
> +{
> +hw_mtrr.msr_mtrr_var[i * 2] = mtrr_state->var_ranges->base;
> +hw_mtrr.msr_mtrr_var[i * 2 + 1] = mtrr_state->var_ranges->mask;
> +}
>
> -for ( i = 0; i < MASK_EXTR(hw_mtrr.msr_mtrr_cap, MTRRcap_VCNT); i++ )
> -{
> -/* save physbase */
> -hw_mtrr.msr_mtrr_var[i*2] =
> -((uint64_t*)mtrr_state->var_ranges)[i*2];
> -/* save physmask */
> -hw_mtrr.msr_mtrr_var[i*2+1] =
> -((uint64_t*)mtrr_state->var_ranges)[i*2+1];
> -}
> +BUILD_BUG_ON(sizeof(hw_mtrr.msr_mtrr_fixed) !=
> + sizeof(mtrr_state->fixed_ranges));
>
> -for ( i = 0; i < NUM_FIXED_MSR; i++ )
> -hw_mtrr.msr_mtrr_fixed[i] =
> -((uint64_t*)mtrr_state->fixed_ranges)[i];
> +memcpy(hw_mtrr.msr_mtrr_fixed, mtrr_state->fixed_ranges,
> sizeof(hw_mtrr.msr_mtrr_fixed));
Long line.
> -if ( hvm_save_entry(MTRR, v->vcpu_id, h, _mtrr) != 0 )
> -return 1;
> +return hvm_save_entry(MTRR, v->vcpu_id, h, _mtrr);
> +}
> +
> +static int hvm_save_mtrr_msr(struct domain *d, hvm_domain_context_t *h)
> +{
> +struct vcpu *v;
> +int err = 0;
> +
> +/* save mtrr */
> +for_each_vcpu(d, v)
> +{
> + err = hvm_save_mtrr_msr_one(v, h);
> + if ( err )
> + break;
> }
> -return 0;
> +return err;
> }
Please, once again, take the opportunity to add the missing blank line
ahead of the function's main (only) return statement. With this (which
can be done while committing, should no other need for a v17 arise)
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] L1TF, and future work
On 15/08/18 14:17, Andrew Cooper wrote: > Hello, Apologies. Getting Dario's correct email address this time. > > Now that the embargo on XSA-273 is up, we can start publicly discussing > the remaining work do, because there is plenty to do. In no particular > order... > > 1) Attempting to shadow dom0 from boot leads to some assertions very > very quickly. Shadowing dom0 after-the-fact leads to some very weird > crashes where whole swathes of the shadow appears to be missing. This > is why, for now, automatic shadowing of dom0 is disabled by default. > > 2) 32bit PV guests which use writeable pagetable support will > automatically get shadowed when the clear the lower half. Ideally, such > guests should be modified to use hypercalls rather than the ptwr > infrastructure (as its more efficient to begin with), but we can > probably work around this in Xen by emulating the next few instructions > until we have a complete PTE (same as the shadow code). > > 3) Toolstack CPUID/MSR work. This is needed for many reasons. > 3a) Able to level MSR_ARCH_CAPS and maxphysaddr to regain some migration > safety. > 3b) Able to report accurate topology to Xen (see point 5) and to guests. > 3c) Able to configure/level the Viridian leaves, and implement the > Viridian L1TF extension. > 3d) Able to configure/level the Xen leaves and implement a similar L1TF > enlightenment. > > 4) The shadow MMIO fastpath truncates the MMIO gfn at 2^28 without any > indication of failure. The most compatible bugfix AFACIT would be to > add an extra nibble's worth of gfn space which gets us to 2^32, and > clamp the guest maxphysaddr calculation at 44 bits. The alternative is > to clamp maxphysaddr to 40 bits, but that will break incoming migrate of > very large shadow guests. > > 4a) The shadow MMIO fastpath needs a runtime clobber, because it will > not function at all on Icelake hardware with a 52-bit physical address > width. Also, it turns out there is an architectural corner case when > levelling maxphysaddr, where some bits which (v)maxphysaddr says should > elicit #PF[RSVD], don't because the actual pipeline address width is larger. > > 5) Core-aware scheduling. At the moment, Xen will schedule arbitrary > guest vcpus on arbitrary hyperthreads. This is bad and wants fixing. > I'll defer to Dario for further details. > > Perhaps the more important longer term action is to start removing > secrets from Xen, because its getting uncomfortably easy to ex-filtrate > data. I'll defer to David for his further plans in this direction. > > I'm sure I've probably missed something in all of this, but this is > enough to begin the discussion. > > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] L1TF, and future work
Hello, Now that the embargo on XSA-273 is up, we can start publicly discussing the remaining work do, because there is plenty to do. In no particular order... 1) Attempting to shadow dom0 from boot leads to some assertions very very quickly. Shadowing dom0 after-the-fact leads to some very weird crashes where whole swathes of the shadow appears to be missing. This is why, for now, automatic shadowing of dom0 is disabled by default. 2) 32bit PV guests which use writeable pagetable support will automatically get shadowed when the clear the lower half. Ideally, such guests should be modified to use hypercalls rather than the ptwr infrastructure (as its more efficient to begin with), but we can probably work around this in Xen by emulating the next few instructions until we have a complete PTE (same as the shadow code). 3) Toolstack CPUID/MSR work. This is needed for many reasons. 3a) Able to level MSR_ARCH_CAPS and maxphysaddr to regain some migration safety. 3b) Able to report accurate topology to Xen (see point 5) and to guests. 3c) Able to configure/level the Viridian leaves, and implement the Viridian L1TF extension. 3d) Able to configure/level the Xen leaves and implement a similar L1TF enlightenment. 4) The shadow MMIO fastpath truncates the MMIO gfn at 2^28 without any indication of failure. The most compatible bugfix AFACIT would be to add an extra nibble's worth of gfn space which gets us to 2^32, and clamp the guest maxphysaddr calculation at 44 bits. The alternative is to clamp maxphysaddr to 40 bits, but that will break incoming migrate of very large shadow guests. 4a) The shadow MMIO fastpath needs a runtime clobber, because it will not function at all on Icelake hardware with a 52-bit physical address width. Also, it turns out there is an architectural corner case when levelling maxphysaddr, where some bits which (v)maxphysaddr says should elicit #PF[RSVD], don't because the actual pipeline address width is larger. 5) Core-aware scheduling. At the moment, Xen will schedule arbitrary guest vcpus on arbitrary hyperthreads. This is bad and wants fixing. I'll defer to Dario for further details. Perhaps the more important longer term action is to start removing secrets from Xen, because its getting uncomfortably easy to ex-filtrate data. I'll defer to David for his further plans in this direction. I'm sure I've probably missed something in all of this, but this is enough to begin the discussion. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RESEND] compat-ioctl/Xen: support at least some IOCTLs of evtchn and privcmd
>>> On 15.08.18 at 14:51, wrote: > On Wed, Aug 15, 2018 at 12:19:00AM -0600, Jan Beulich wrote: >> While this is only a start (IOCTL_PRIVCMD_MMAP* and IOCTL_PRIVCMD_DM_OP >> require more work), it at least allows some simple operations (like >> "xl dmesg") which have always been available on XenoLinux to work again >> with a 64-bit kernel underneath a 32-bit distro. >> >> Signed-off-by: Jan Beulich >> Acked-by: Juergen Gross > > > Nacked-by: Al Viro > > This belongs in drivers/xen/privcmd.c, not in fs/compat_ioctl.c > *ANY* single-driver ioctl definitely should be handled by ->compat_ioctl() > method and any patches dumping such stuff into fs/compat_ioctl.c will be > rejected. Okay, I'll see about doing this; I have to admit I was unaware of ->compat_ioctl()'s existence. It would be rather helpful if the header of compat_ioctl.c indicated what you say. Without that, I've simply gone by the observation that there are things in the file which according to what you say shouldn't be there, and I've then wrongly implied adding the Xen stuff here would be fine. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 12/12] xen/domain: Allocate d->vcpu[] in domain_create()
>>> On 13.08.18 at 12:01, wrote:
> @@ -423,6 +436,11 @@ struct domain *domain_create(domid_t domid,
>
> sched_destroy_domain(d);
>
> +if ( d->max_vcpus )
> +{
> +d->max_vcpus = 0;
> +XFREE(d->vcpu);
> +}
> if ( init_status & INIT_arch )
> arch_domain_destroy(d);
I'm not sure it is a good idea to free the vcpus this early, in particular
before arch_domain_destroy().
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -554,16 +554,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
>
> ret = -EINVAL;
> if ( (d == current->domain) || /* no domain_pause() */
> - (max > domain_max_vcpus(d)) )
> + (max != d->max_vcpus) ) /* max_vcpus set up in createdomain */
> break;
>
> -/* Until Xenoprof can dynamically grow its vcpu-s array... */
> -if ( d->xenoprof )
> -{
> -ret = -EAGAIN;
> -break;
> -}
> -
> /* Needed, for example, to ensure writable p.t. state is synced. */
> domain_pause(d);
>
> @@ -581,38 +574,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
> }
> }
>
> -/* We cannot reduce maximum VCPUs. */
> -ret = -EINVAL;
> -if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
> -goto maxvcpu_out;
> -
> -/*
> - * For now don't allow increasing the vcpu count from a non-zero
> - * value: This code and all readers of d->vcpu would otherwise need
> - * to be converted to use RCU, but at present there's no tools side
> - * code path that would issue such a request.
> - */
> -ret = -EBUSY;
> -if ( (d->max_vcpus > 0) && (max > d->max_vcpus) )
> -goto maxvcpu_out;
> -
> ret = -ENOMEM;
> online = cpupool_domain_cpumask(d);
> -if ( max > d->max_vcpus )
> -{
> -struct vcpu **vcpus;
> -
> -BUG_ON(d->vcpu != NULL);
> -BUG_ON(d->max_vcpus != 0);
> -
> -if ( (vcpus = xzalloc_array(struct vcpu *, max)) == NULL )
> -goto maxvcpu_out;
> -
> -/* Install vcpu array /then/ update max_vcpus. */
> -d->vcpu = vcpus;
> -smp_wmb();
> -d->max_vcpus = max;
> -}
>
> for ( i = 0; i < max; i++ )
> {
With all of this dropped, I think the domctl should be renamed. By
dropping its "max" input at the same time, there would then also
no longer be a need to check that the value matches what was
stored during domain creation.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] x86 Community Call - Wed Aug 15, 14:00 - 15:00 UTC - Agenda items
Hi all: I put an agenda + minutes link at https://docs.google.com/document/d/1zf9saqOvxAsIDvHPIFpzy56zsUdhu4LcHouQ0Uf2RGw/edit?usp=sharing I added L1 Terminal Fault to the agenda (as this likely will come up under AOB anyway) Lars On 14/08/2018, 09:12, "Sergey Dyasli" wrote: On Mon, 2018-08-13 at 02:54 -0600, Jan Beulich wrote: > > > > On 13.08.18 at 09:46, wrote: > > > > proposed topics so far: > > * 4.10+ changes to Xen's memory scrubbing: discussion of the changes > > that made to it in recent versions of Xen (4.10+) - Christopher > > * Project Management stuff to keep the Momentum going - primarily > > looking for Intel updates > > Timing is not really good for this, but deferring to the next meeting is > also too long. I realize everyone's quite busy, and I'm myself also > struggling to get to look at > - VMX MSRs policy for Nested Virt: part 1 (I've looked over this, and I > think it's okay, but I also think that in particular nested stuff wants > both maintainers and Andrew to look over) Regarding VMX MSRs, I plan to refresh the series once the new CPUID+MSR infrastructure is in place. This will allow to configure VMX features for each guest independently. -- Thanks, Sergey ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 06/12] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create()
On 15/08/18 14:04, Julien Grall wrote:
> Hi Andrew,
>
> On 08/13/2018 11:01 AM, Andrew Cooper wrote:
>> ... rather than setting the limits up after domain_create() has
>> completed.
>>
>> This removes all the gnttab infrastructure for calculating the number
>> of dom0
>> grant frames, opting instead to require the dom0 construction code to
>> pass a
>> sane value in via the configuration.
>>
>> In practice, this now means that there is never a partially
>> constructed grant
>> table for a reference-able domain.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Stefano Stabellini
>> CC: Julien Grall
>> CC: Wei Liu
>>
>> v2:
>> * Split/rearrange to avoid the post-domain-create error path.
>> ---
>> xen/arch/arm/domain_build.c | 3 ++-
>> xen/arch/arm/setup.c | 12
>> xen/arch/x86/setup.c | 3 +++
>> xen/common/domain.c | 3 ++-
>> xen/common/grant_table.c | 16 +++-
>> xen/include/asm-arm/grant_table.h | 12
>> xen/include/asm-x86/grant_table.h | 5 -
>> xen/include/xen/grant_table.h | 6 ++
>> 8 files changed, 24 insertions(+), 36 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 1351572..737e0f3 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -2079,7 +2079,8 @@ static void __init find_gnttab_region(struct
>> domain *d,
>> * enough space for a large grant table
>> */
>> kinfo->gnttab_start = __pa(_stext);
>> - kinfo->gnttab_size = gnttab_dom0_frames() << PAGE_SHIFT;
>> + kinfo->gnttab_size = min_t(unsigned int, opt_max_grant_frames,
>> + PFN_DOWN(_etext - _stext)) <<
>> PAGE_SHIFT;
>
>
> I agree with Jan's comment on v1 that there is a risk someone will
> update the size here but ...
>
>
>> #ifdef CONFIG_ARM_32
>> /*
>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>> index 45f3841..3d3b30c 100644
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -693,6 +694,17 @@ void __init start_xen(unsigned long
>> boot_phys_offset,
>> struct domain *dom0;
>> struct xen_domctl_createdomain dom0_cfg = {
>> .max_evtchn_port = -1,
>> +
>> + /*
>> + * The region used by Xen on the memory will never be mapped
>> in DOM0
>> + * memory layout. Therefore it can be used for the grant table.
>> + *
>> + * Only use the text section as it's always present and will
>> contain
>> + * enough space for a large grant table
>> + */
>> + .max_grant_frames = min_t(unsigned int, opt_max_grant_frames,
>> + PFN_DOWN(_etext - _stext)),
>
> ... not here. So I would prefer if we either keep an helper to find
> the size of pass that size around to domain_build. Do we store the
> size in the domain information?
I have to admit that I'm somewhat perplexed by ARM's
find_gnttab_region(), and I'm not sure why it exists.
The value is available from d->grant_table.max_grant_frames but ISTR
finding that the order of construction meant that it wasn't available
when needed (although this was all from code inspection, so I could very
easily be wrong).
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 125898: tolerable FAIL - PUSHED
flight 125898 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/125898/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125702 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125702 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125702 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125702 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125702 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125702 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 125702 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125702 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 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-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-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-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install 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 version targeted for testing: linux94710cac0ef4ee177a63b5227664b38c95bbf703 baseline version: linux527838d470e3a6e79e8ee9d5ddf28920df2a196e Last test of basis 125702 2018-07-31 14:25:44 Z 14 days Failing since125735 2018-08-01 18:37:38 Z 13 days8 attempts Testing same since 125898 2018-08-13 21:20:55 Z1 days1 attempts People who touched revisions under test: Adi Nissim Al Viro Alaa Hleihel Alexei Starovoitov Alexey Kodanev Andrew Lunn Andrew Morton Andrey Ryabinin Anil Gurumurthy Anna-Maria Gleixner Anton Vasilyev Ard Biesheuvel Arend van Spriel Arjun Vynipadath Arnaldo Carvalho de Melo Artem Bityutskiy Avinash Repaka Bart Van Assche Benjamin Tissoires Bjorn Helgaas Björn Töpel Boris Brezillon Calvin Walton chen jie Colin Ian King Cong Wang Dan Carpenter Daniel Borkmann dann frazier Darrick J. Wong Dave Airlie David Howells David S. Miller Davidlohr Bueso Dmitry Bogdanov Dmitry Safonov Douglas Gilbert Eli Cohen Emmanuel Grumbach Eric Dumazet Eric Sandeen Erik Schmauss Eugeniy Paltsev Eyal Birger Feras Daoud Florian Fainelli Florian Westphal Frederic Barrat Frederic Weisbecker Gal Pressman Ganesh Goudar George Cherian Govindarajulu Varadarajan Guenter Roeck Guillaume Nault
Re: [Xen-devel] [PATCH v2 06/12] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create()
Hi Andrew,
On 08/13/2018 11:01 AM, Andrew Cooper wrote:
... rather than setting the limits up after domain_create() has completed.
This removes all the gnttab infrastructure for calculating the number of dom0
grant frames, opting instead to require the dom0 construction code to pass a
sane value in via the configuration.
In practice, this now means that there is never a partially constructed grant
table for a reference-able domain.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Wei Liu
v2:
* Split/rearrange to avoid the post-domain-create error path.
---
xen/arch/arm/domain_build.c | 3 ++-
xen/arch/arm/setup.c | 12
xen/arch/x86/setup.c | 3 +++
xen/common/domain.c | 3 ++-
xen/common/grant_table.c | 16 +++-
xen/include/asm-arm/grant_table.h | 12
xen/include/asm-x86/grant_table.h | 5 -
xen/include/xen/grant_table.h | 6 ++
8 files changed, 24 insertions(+), 36 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 1351572..737e0f3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2079,7 +2079,8 @@ static void __init find_gnttab_region(struct domain *d,
* enough space for a large grant table
*/
kinfo->gnttab_start = __pa(_stext);
-kinfo->gnttab_size = gnttab_dom0_frames() << PAGE_SHIFT;
+kinfo->gnttab_size = min_t(unsigned int, opt_max_grant_frames,
+ PFN_DOWN(_etext - _stext)) << PAGE_SHIFT;
I agree with Jan's comment on v1 that there is a risk someone will
update the size here but ...
#ifdef CONFIG_ARM_32
/*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 45f3841..3d3b30c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -693,6 +694,17 @@ void __init start_xen(unsigned long boot_phys_offset,
struct domain *dom0;
struct xen_domctl_createdomain dom0_cfg = {
.max_evtchn_port = -1,
+
+/*
+ * The region used by Xen on the memory will never be mapped in DOM0
+ * memory layout. Therefore it can be used for the grant table.
+ *
+ * Only use the text section as it's always present and will contain
+ * enough space for a large grant table
+ */
+.max_grant_frames = min_t(unsigned int, opt_max_grant_frames,
+ PFN_DOWN(_etext - _stext)),
... not here. So I would prefer if we either keep an helper to find the
size of pass that size around to domain_build. Do we store the size in
the domain information?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 11/12] xen/dom0: Arrange for dom0_cfg to contain the real max_vcpus value
>>> On 13.08.18 at 12:01, wrote: > Make dom0_max_vcpus() a common interface, and implement it on ARM by splitting > the existing alloc_dom0_vcpu0() function in half. > > As domain_create() doesn't yet set up the vcpu array, the max value is also > passed into alloc_dom0_vcpu0(). This is temporary for bisectibility and > removed in the following patch. > > Signed-off-by: Andrew Cooper > Reviewed-by: Julien Grall Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 04/12] xen/evtchn: Pass max_evtchn_port into evtchn_init()
Hi Andrew,
On 08/13/2018 11:01 AM, Andrew Cooper wrote:
... rather than setting it up once domain_create() has completed. This
involves constructing a default value for dom0.
No practical change in functionality.
Signed-off-by: Andrew Cooper
For the Arm bits:
Acked-by: Julien Grall
Cheers,
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Wei Liu
---
xen/arch/arm/setup.c | 4 +++-
xen/arch/x86/setup.c | 1 +
xen/common/domain.c| 2 +-
xen/common/domctl.c| 3 ---
xen/common/event_channel.c | 4 ++--
xen/include/xen/sched.h| 2 +-
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 7d40a84..45f3841 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -691,7 +691,9 @@ void __init start_xen(unsigned long boot_phys_offset,
const char *cmdline;
struct bootmodule *xen_bootmodule;
struct domain *dom0;
-struct xen_domctl_createdomain dom0_cfg = {};
+struct xen_domctl_createdomain dom0_cfg = {
+.max_evtchn_port = -1,
+};
dcache_line_bytes = read_dcache_line_bytes();
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8301de8..015099f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -681,6 +681,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
};
struct xen_domctl_createdomain dom0_cfg = {
.flags = XEN_DOMCTL_CDF_s3_integrity,
+.max_evtchn_port = -1,
};
/* Critical region without IDT or TSS. Any fault is deadly! */
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 749722b..171d25e 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -362,7 +362,7 @@ struct domain *domain_create(domid_t domid,
radix_tree_init(>pirq_tree);
-if ( (err = evtchn_init(d)) != 0 )
+if ( (err = evtchn_init(d, config->max_evtchn_port)) != 0 )
goto fail;
init_status |= INIT_evtchn;
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 3a68fc9..0ef554a 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -540,9 +540,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
break;
}
-d->max_evtchn_port = min_t(unsigned int,
- op->u.createdomain.max_evtchn_port,
INT_MAX);
-
ret = 0;
op->domain = d->domain_id;
copyback = 1;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index c620465..41cbbae 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1284,10 +1284,10 @@ void evtchn_check_pollers(struct domain *d, unsigned
int port)
}
}
-int evtchn_init(struct domain *d)
+int evtchn_init(struct domain *d, unsigned int max_port)
{
evtchn_2l_init(d);
-d->max_evtchn_port = INT_MAX;
+d->max_evtchn_port = min_t(unsigned int, max_port, INT_MAX);
d->evtchn = alloc_evtchn_bucket(d, 0);
if ( !d->evtchn )
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 3c35473..51ceebe 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -134,7 +134,7 @@ struct evtchn
#endif
} __attribute__((aligned(64)));
-int evtchn_init(struct domain *d); /* from domain_create */
+int evtchn_init(struct domain *d, unsigned int max_port);
void evtchn_destroy(struct domain *d); /* from domain_kill */
void evtchn_destroy_final(struct domain *d); /* from complete_domain_destroy
*/
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 09/12] xen/domain: Call arch_domain_create() as early as possible in domain_create()
>>> On 13.08.18 at 12:01, wrote: > This is in preparation to set up d->max_cpus and d->vcpu[] in domain_create(), > and allow later parts of domain construction to have access to the values. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 08/12] xen/gnttab: Fold grant_table_{create, set_limits}() into grant_table_init()
>>> On 13.08.18 at 12:01, wrote:
> Now that the max_{grant,maptrack}_frames are specified from the very beginning
> of grant table construction, the various initialisation functions can be
> folded together and simplified as a result.
>
> Leave grant_table_init() as the public interface, which is more consistent
> with other subsystems.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 06/12] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create()
>>> On 13.08.18 at 12:01, wrote: > ... rather than setting the limits up after domain_create() has completed. > > This removes all the gnttab infrastructure for calculating the number of dom0 > grant frames, opting instead to require the dom0 construction code to pass a > sane value in via the configuration. > > In practice, this now means that there is never a partially constructed grant > table for a reference-able domain. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries
On 15/08/18 13:41, Jan Beulich wrote:
On 10.08.18 at 16:48, wrote:
>> When emulating a rep I/O operation it is possible that the ioreq will
>> describe a single operation that spans multiple GFNs. This is fine as long
>> as all those GFNs fall within an MMIO region covered by a single device
>> model, but unfortunately the higher levels of the emulation code do not
>> guarantee that. This is something that should almost certainly be fixed,
>> but in the meantime this patch makes sure that MMIO is truncated at GFN
>> boundaries and hence the appropriate device model is re-evaluated for each
>> target GFN.
>>
>> NOTE: This patch does not deal with the case of a single MMIO operation
>> spanning a GFN boundary. That is more complex to deal with and is
>> deferred to a subsequent patch.
>>
>> Signed-off-by: Paul Durrant
> Reviewed-by: Jan Beulich
> with a type change request:
>
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -184,6 +184,25 @@ static int hvmemul_do_io(
>> hvmtrace_io_assist();
>> }
>>
>> +/*
>> + * Make sure that we truncate rep MMIO at any GFN boundary. This is
>> + * necessary to ensure that the correct device model is targetted
>> + * or that we correctly handle a rep op spanning MMIO and RAM.
>> + */
>> +if ( unlikely(p.count > 1) && p.type == IOREQ_TYPE_COPY )
>> +{
>> +unsigned long off = p.addr & ~PAGE_MASK;
> If this was "unsigned int", all calculations below could be slightly
> cheaper 32-bit ones and ...
>
>> +if ( PAGE_SIZE - off < p.size ) /* single rep spans GFN */
>> +p.count = 1;
>> +else
>> +p.count = min_t(unsigned long,
> ... this could be just min(), as long as ...
>
>> +p.count,
>> +((p.df ? (off + p.size) : (PAGE_SIZE - off)) /
> ... the 3rd arg of the ?: gets cast to unsigned int. If you agree, I'd
> be fine doing the adjustments while committing.
Paul is OoO for a while now. In lieu, I'd say "yes please" to these
suggestions.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 04/12] xen/evtchn: Pass max_evtchn_port into evtchn_init()
>>> On 13.08.18 at 12:01, wrote: > ... rather than setting it up once domain_create() has completed. This > involves constructing a default value for dom0. > > No practical change in functionality. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/hvm/emulate: make sure rep I/O emulation does not cross GFN boundaries
>>> On 10.08.18 at 16:48, wrote:
> When emulating a rep I/O operation it is possible that the ioreq will
> describe a single operation that spans multiple GFNs. This is fine as long
> as all those GFNs fall within an MMIO region covered by a single device
> model, but unfortunately the higher levels of the emulation code do not
> guarantee that. This is something that should almost certainly be fixed,
> but in the meantime this patch makes sure that MMIO is truncated at GFN
> boundaries and hence the appropriate device model is re-evaluated for each
> target GFN.
>
> NOTE: This patch does not deal with the case of a single MMIO operation
> spanning a GFN boundary. That is more complex to deal with and is
> deferred to a subsequent patch.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
with a type change request:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -184,6 +184,25 @@ static int hvmemul_do_io(
> hvmtrace_io_assist();
> }
>
> +/*
> + * Make sure that we truncate rep MMIO at any GFN boundary. This is
> + * necessary to ensure that the correct device model is targetted
> + * or that we correctly handle a rep op spanning MMIO and RAM.
> + */
> +if ( unlikely(p.count > 1) && p.type == IOREQ_TYPE_COPY )
> +{
> +unsigned long off = p.addr & ~PAGE_MASK;
If this was "unsigned int", all calculations below could be slightly
cheaper 32-bit ones and ...
> +if ( PAGE_SIZE - off < p.size ) /* single rep spans GFN */
> +p.count = 1;
> +else
> +p.count = min_t(unsigned long,
... this could be just min(), as long as ...
> +p.count,
> +((p.df ? (off + p.size) : (PAGE_SIZE - off)) /
... the 3rd arg of the ?: gets cast to unsigned int. If you agree, I'd
be fine doing the adjustments while committing.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RESEND] compat-ioctl/Xen: support at least some IOCTLs of evtchn and privcmd
Please wire up a compat_ioctl handler for the xen privcmd handler instead of adding these to a global table. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 125918: tolerable all pass - PUSHED
flight 125918 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/125918/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-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 version targeted for testing: xen 80cdb33cb7a96c3355b35ec620f1798fe3be1048 baseline version: xen aa67b97ed34279c43a43d9ca46727b5746caa92e Last test of basis 125910 2018-08-14 18:00:30 Z0 days Testing same since 125918 2018-08-15 10:00:26 Z0 days1 attempts People who touched revisions under test: Julien Grall Roger Pau Monne Roger Pau Monné Simon Rowe Stefano Stabellini Stefano Stabellini Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git aa67b97ed3..80cdb33cb7 80cdb33cb7a96c3355b35ec620f1798fe3be1048 -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] VMX: make vmx_read_guest_msr() cope with callers not checking its return value
>>> On 15.08.18 at 13:39, wrote:
> On 15/08/18 12:34, Jan Beulich wrote:
>> It took till the 4.5 backports of the L1TF prereqs that gcc 8.2 finally
>> noticed that the vPMU callers, not checking the function's return value,
>> may consume uninitialized data. Guard against this by storing zero on
>> the error path.
>>
>> Signed-off-by: Jan Beulich
>
> vPMU really is the gift which keeps on giving...
>
>>
>> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
>> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
>> @@ -586,7 +586,10 @@ static inline int vmx_read_guest_msr(con
>> const struct vmx_msr_entry *ent = vmx_find_msr(v, msr, VMX_MSR_GUEST);
>>
>> if ( !ent )
>> +{
>> +*val = 0;
>> return -ESRCH;
>> +}
>>
>> *val = ent->data;
>>
>
> You want a similar adjustment in vmx_read_guest_loadonly_msr()
> immediately below, which I believe is only applicable to staging atm.
Oh, indeed - coming from 4.5 I didn't pay enough attention here.
> With that, Reviewed-by: Andrew Cooper
Thanks, Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] VMX: make vmx_read_guest_msr() cope with callers not checking its return value
On 15/08/18 12:34, Jan Beulich wrote:
> It took till the 4.5 backports of the L1TF prereqs that gcc 8.2 finally
> noticed that the vPMU callers, not checking the function's return value,
> may consume uninitialized data. Guard against this by storing zero on
> the error path.
>
> Signed-off-by: Jan Beulich
vPMU really is the gift which keeps on giving...
>
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -586,7 +586,10 @@ static inline int vmx_read_guest_msr(con
> const struct vmx_msr_entry *ent = vmx_find_msr(v, msr, VMX_MSR_GUEST);
>
> if ( !ent )
> +{
> +*val = 0;
> return -ESRCH;
> +}
>
> *val = ent->data;
>
You want a similar adjustment in vmx_read_guest_loadonly_msr()
immediately below, which I believe is only applicable to staging atm.
With that, Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] VMX: make vmx_read_guest_msr() cope with callers not checking its return value
It took till the 4.5 backports of the L1TF prereqs that gcc 8.2 finally
noticed that the vPMU callers, not checking the function's return value,
may consume uninitialized data. Guard against this by storing zero on
the error path.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -586,7 +586,10 @@ static inline int vmx_read_guest_msr(con
const struct vmx_msr_entry *ent = vmx_find_msr(v, msr, VMX_MSR_GUEST);
if ( !ent )
+{
+*val = 0;
return -ESRCH;
+}
*val = ent->data;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/pv: Use xmemdup() for cpuidmasks, rather than opencoding it
>>> On 15.08.18 at 11:58, wrote: > On Wed, Aug 15, 2018 at 10:54:11AM +0100, Andrew Cooper wrote: >> Signed-off-by: Andrew Cooper > > Reviewed-by: Wei Liu 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] qemu-trad: stop using the default IOREQ server
Paul Durrant writes ("[PATCH] qemu-trad: stop using the default IOREQ server"):
> Because qemu-trad is using the legacy HVM param mechanism of hooking into
> Xen, it means that Xen has to maintain the notion of a 'default' IOREQ
> server which is where all I/O goes if no other device model claims it.
> Maintaining this code in Xen has a cost and it would be good if the project
> no longer had to pay it.
>
> This patch makes the necessary minimal changes to the qemu-trad to use the
> IOREQ server API to hook into Xen. This means the default IOREQ server
> will no longer be in use and thus it no longer needs to be maintained.
That is a good thing.
I looked overr the patch. Most of it is about what I would have
expected.
But I did want to query this:
> +case IOREQ_TYPE_PCI_CONFIG: {
> +uint32_t sbdf = req->addr >> 32;
> +uint32_t val;
> +
> +/* Fake out to 0xcf8 */
> +val = (1u << 31) |
> +((req->addr & 0x0f00) << 16) |
> +((sbdf & 0x) << 8) |
> +(req->addr & 0xfc);
> +do_outp(env, 0xcf8, 4, val);
> +
> +/* Now fake I/O to 0xcfc */
> +req->addr = 0xcfc | (req->addr & 0x03);
> +cpu_ioreq_pio(env, req);
> +break;
> +}
This looks messy. Can someone please explain why this is needed and
why it is best to do it this way ?
(I'm don't know much about PCI, which is probably a contributory
factor in my querying this. Sorry about that.)
Regards,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.6] amend "x86/Intel: Mitigations for GPZ SP4 - Speculative Store Bypass"
On 15/08/18 09:21, Jan Beulich wrote: > This is part of CVE-2018-3639 / XSA-263. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: write to correct variable in parse_pv_l1tf()
On 15/08/18 11:34, Jan Beulich wrote: > Apparently a copy-and-paste mistake. > > Signed-off-by: Jan Beulich Yikes. Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86: write to correct variable in parse_pv_l1tf()
Apparently a copy-and-paste mistake.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -232,7 +232,7 @@ static __init int parse_pv_l1tf(const ch
/* Interpret 'pv-l1tf' alone in its positive boolean form. */
if ( *s == '\0' )
-opt_xpti = OPT_PV_L1TF_DOM0 | OPT_PV_L1TF_DOMU;
+opt_pv_l1tf = OPT_PV_L1TF_DOM0 | OPT_PV_L1TF_DOMU;
do {
ss = strchr(s, ',');
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-coverity test] 125916: all pass - PUSHED
flight 125916 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/125916/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen aa67b97ed34279c43a43d9ca46727b5746caa92e baseline version: xen ed5f8d9ca47e69e30221c37ec812f2b38af19d83 Last test of basis 125756 2018-08-05 09:18:24 Z 10 days Testing same since 125916 2018-08-15 09:19:04 Z0 days1 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Christian Lindig Doug Goldstein George Dunlap Jan Beulich Juergen Gross Julien Grall Kevin Tian Marek Marczykowski-Górecki Paul Durrant Razvan Cojocaru Roger Pau Monné Stefano Stabellini Wei Liu jobs: coverity-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git ed5f8d9ca4..aa67b97ed3 aa67b97ed34279c43a43d9ca46727b5746caa92e -> coverity-tested/smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/pv: Use xmemdup() for cpuidmasks, rather than opencoding it
On Wed, Aug 15, 2018 at 10:54:11AM +0100, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/pv: Use xmemdup() for cpuidmasks, rather than opencoding it
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/pv/domain.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
index 3230ac6..52108d4 100644
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -240,13 +240,9 @@ int pv_domain_initialise(struct domain *d)
goto fail;
clear_page(d->arch.pv_domain.gdt_ldt_l1tab);
-if ( levelling_caps & ~LCAP_faulting )
-{
-d->arch.pv_domain.cpuidmasks = xmalloc(struct cpuidmasks);
-if ( !d->arch.pv_domain.cpuidmasks )
-goto fail;
-*d->arch.pv_domain.cpuidmasks = cpuidmask_defaults;
-}
+if ( levelling_caps & ~LCAP_faulting &&
+ (d->arch.pv_domain.cpuidmasks = xmemdup(_defaults)) == NULL
)
+goto fail;
rc = create_perdomain_mapping(d, GDT_LDT_VIRT_START,
GDT_LDT_MBYTES << (20 - PAGE_SHIFT),
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] production-config: Temporarily drop arm64
Hi, On 08/15/2018 12:25 AM, Rich Persaud wrote: On Aug 14, 2018, at 18:46, Julien Grall wrote: Hi Rich, On 08/14/2018 11:42 PM, Rich Persaud wrote: On Aug 13, 2018, at 10:57, Ian Jackson wrote: Both our arm64 boxes are out of commission and repairing them is taking too long. Apologies if this is already documented elsewhere - does OSStest use Qemu for arm64 testing? Osstest does not use QEMU for testing, but I think it would be too slow to have result in timely manner and use x86 resource as well. To avoid having zero test coverage for one target architecture, it may be acceptable to temporarily reduce test capacity for other target architectures. QEMU has the advantage of being faster to "rack" a test architecture for temporary use. Well, arm64 test coverage was already reduced because we had only 2 platforms ready for testing. I can hardly imagine how this code be reduced more for fitting QEMU. Beware that we compile natively in Osstest so this will take an awful lot of time here. However, the main problem here is not the lack of platform but the lack of time for OSSTest team (mostly Ian and Wei) to investigate and bring-up new platforms. Maybe you can help finding contributors to help on Arm64? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Armv8-A: Not able to enable secondary CPUs in Hikey960 board
HI Julien, As you suggested, I enabled early printk for hikey960 in xen-4.8 stable branch and xen-4.11 stable branch. Please find below xen-4.8 log after early printk: -- Using modules provided by bootloader in FDT Xen 4.8.5-pre (c/s Mon Jul 30 12:10:58 2018 +0200 git:aa45015-dirty) EFI loader - UART enabled - - CPU booting - - Current EL 0008 - - Xen starting at EL2 - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: - 1abf (XEN) RAM: 1ad88000 - 31ff (XEN) RAM: 32101000 - 3dff (XEN) RAM: 4000 - 4ae9 (XEN) RAM: 89cc - b83bdfff (XEN) RAM: b9b09000 - b9bc (XEN) RAM: b9c7 - b9c72fff (XEN) RAM: b9c74000 - b9d5 (XEN) RAM: ba125000 - ba12bfff (XEN) RAM: ba12c000 - bdd1bfff (XEN) RAM: bdd1c000 - bddccfff (XEN) RAM: bddcd000 - bde82fff (XEN) RAM: bde83000 - bef5 (XEN) RAM: bef6 - bf0e (XEN) RAM: bf0f - bf13 (XEN) RAM: bf19 - bf193fff (XEN) RAM: bf194000 - bfff (XEN) RAM: c000 - dfff (XEN) RAM: 0002 - 00021fff (XEN) (XEN) MODULE[0]: b83be000 - b83cf000 Device Tree (XEN) MODULE[1]: b84e - b9996200 Kernel console=tty0 console=hvc0 root=/dev/sdd10 rw efi=noruntime (XEN) (XEN) Command line: loglvl=all console=dtuart dtuart=/soc/serial@fff32000 efi=no-rs (XEN) Placing Xen at 0x1aa0-0x1ac0 (XEN) Update BOOTMOD_XEN from b83cf000-b84cfd81 => 1aa0-1ab00d81 (XEN) Domain heap initialised (XEN) Platform: Generic System (XEN) Looking for dtuart at "/soc/serial@fff32000", options "" Xen 4.8.5-pre (XEN) Xen version 4.8.5-pre (omkar.bolla@) (aarch64-linux-gnu-gcc (Linaro GCC 7.1-2017.05) 7.1.1 20170510) debug=n Wed Aug 15 13:20:23 IST 2018 (XEN) Latest ChangeSet: Mon Jul 30 12:10:58 2018 +0200 git:aa45015-dirty (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4 (XEN) 64-bit Execution: (XEN) Processor Features: (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 10305106 (XEN) Auxiliary Features: (XEN) Memory Model Features: 1122 (XEN) ISA Features: 00011120 (XEN) 32-bit Execution: (XEN) Processor Features: 0131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10201105 4000 0126 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Using PSCI-1.1 for SMP bringup (XEN) SMP: Allowing 8 CPUs (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 1920 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=e82b1000 (XEN) gic_cpu_addr=e82b2000 (XEN) gic_hyp_addr=e82b4000 (XEN) gic_vcpu_addr=e82b6000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 384 lines, 8 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 64 KiB. (XEN) Bringing up CPU1 - CPU 0001 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 1 booted. (XEN) Bringing up CPU2 - CPU 0002 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 2 booted. (XEN) Bringing up CPU3 - CPU 0003 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 3 booted. (XEN) Bringing up CPU4 - CPU 0100 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 4 booted. (XEN) Bringing up CPU5 - CPU 0101 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 5 booted. (XEN) Bringing up CPU6 - CPU 0102 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 6 booted. (XEN) Bringing up CPU7 - CPU 0103 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 7 booted. (XEN) Brought up 8 CPUs (XEN) P2M: 40-bit IPA with
Re: [Xen-devel] [PATCH for-4.7] arm: constify atomic_read parameter
On Wed, Aug 15, 2018 at 09:51:35AM +0100, Julien Grall wrote: > > > On 08/15/2018 09:29 AM, Andrew Cooper wrote: > > On 15/08/2018 09:28, Wei Liu wrote: > > > ded2a37d63 added const to atomic_read. Do the same for Arm > > > counterpart. > > > > > > Signed-off-by: Wei Liu > > > > Acked-by: Andrew Cooper > > > > Most likely needed for 4.6 as well. > > Feel free to add my ack on 4.6 patch as well: > > Acked-by: Julien Grall . Thanks. I will commit both patches shortly. > > > > > ~Andrew > > > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-3.18 test] 125899: FAIL
flight 125899 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/125899/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvopsbroken in 125874 build-arm64 broken in 125874 build-arm64-xsm broken in 125874 build-arm64-pvops 3 capture-logs broken in 125874 REGR. vs. 125658 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-cubietruck 6 xen-installfail in 125874 pass in 125899 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail pass in 125874 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail pass in 125874 Regressions which are regarded as allowable (not blocking): build-arm64-pvops 2 hosts-allocate broken in 125874 REGR. vs. 125658 build-arm64-xsm 2 hosts-allocate broken in 125874 REGR. vs. 125658 build-arm64 2 hosts-allocate broken in 125874 REGR. vs. 125658 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 1 build-check(1) blocked in 125874 n/a test-arm64-arm64-xl 1 build-check(1) blocked in 125874 n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 125874 n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked in 125874 n/a build-arm64-libvirt 1 build-check(1) blocked in 125874 n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked in 125874 n/a build-arm64-xsm 3 capture-logs broken in 125874 blocked in 125658 build-arm64 3 capture-logs broken in 125874 blocked in 125658 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 125658 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125658 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125658 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125658 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125658 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 125658 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 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-rtds 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-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass
Re: [Xen-devel] [PATCH for-4.7] arm: constify atomic_read parameter
On 08/15/2018 09:29 AM, Andrew Cooper wrote: On 15/08/2018 09:28, Wei Liu wrote: ded2a37d63 added const to atomic_read. Do the same for Arm counterpart. Signed-off-by: Wei Liu Acked-by: Andrew Cooper Most likely needed for 4.6 as well. Feel free to add my ack on 4.6 patch as well: Acked-by: Julien Grall . ~Andrew -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
