[Xen-devel] [xen-unstable-smoke test] 127242: regressions - FAIL
flight 127242 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 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 a9a2a761f75126d908612c64fabe6adde2b6d2b9
baseline version:
xen 16bbf8e7b39b50457bb2f6547f166bd54d50e4cd
Last test of basis 127212 2018-09-03 13:00:29 Z0 days
Failing since127215 2018-09-03 16:00:27 Z0 days6 attempts
Testing same since 127219 2018-09-03 19:00:33 Z0 days5 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
Razvan Cojocaru
Roger Pau Monné
Tim Deegan
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
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 a9a2a761f75126d908612c64fabe6adde2b6d2b9
Author: Andrew Cooper
Date: Wed Aug 1 13:48:33 2018 +
x86/hvm: Fix mapping corner case during task switching
hvm_map_entry() can fail for a number of reasons, including for a misaligned
LDT/GDT access which crosses a 4K boundary. Architecturally speaking, this
should be fixed, but Long Mode doesn't support task switches, and no 32bit
OS
is going to misalign its LDT/GDT base, which is why this task isn't very
high
on the TODO list.
However, the hvm_map_fail error label returns failure without raising an
exception, which interferes with hvm_task_switch()'s exception tracking, and
can cause it to finish and return to guest context as if the task switch had
completed successfully.
Resolve this corner case by folding all the failure paths together, which
causes an hvm_map_entry() failure to result in #TS[SEL]. hvm_unmap_entry()
copes fine with a NULL pointer so can be called unconditionally.
In practice, this is just a latent corner case as all hvm_map_entry()
failures
crash the domain, but it should be fixed nevertheless.
Finally, rename hvm_load_segment_selector() to task_switch_load_seg() to
avoid
giving the impression that it is usable for general segment loading.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit 1f0598a1beb6bbaa838dec4f321af543d3b96c7a
Author: Andrew Cooper
Date: Wed Jan 24 16:43:55 2018 +
x86/mm: Drop {HAP,SHADOW}_ERROR() wrappers
Unlike the PRINTK/DEBUG wrappers, these go straight out to the console,
rather
than ending up in the debugtrace buffer.
A number of these users are followed by domain_crash(), and future changes
will want to combine the printk() into the domain_crash() call. Expand
these
wrappers in place, using XENLOG_ERR before a BUG(), and XENLOG_G_ERR before
a
domain_crash().
Perfom some %pv/PRI_mfn/etc cleanup while modifying the invocations, and
explicitly drop some calls which are unnecessary (bad shadow op, and the
empty
stubs for incorrect sh_map_and_validate_gl?e() calls).
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Tim Deegan
commit 4f9b0dbb33aca70cdb61c2988866cbedb4181702
Author: Andrew Cooper
Date: Mon Sep 3 17:45:52 2018 +0100
xen/x86: Ignore the automatically generated
Re: [Xen-devel] Ping VT-x: [PATCH 10/11] x86/vmx: Work around VMEntry failure when Single Stepping in an STI shadow
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Monday, September 3, 2018 6:40 PM > > On 04/06/18 14:59, Andrew Cooper wrote: > > See the code comment for the details. > > > > Signed-off-by: Andrew Cooper Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU
In a classic HVI + Xen setup, the introspection engine would monitor
legacy guest page-tables by marking them read-only inside the EPT; this
way any modification explicitly made by the guest or implicitly made by
the CPU page walker would trigger an EPT violation, which would be
forwarded by Xen to the SVA and thus the HVI agent. The HVI agent would
analyse the modification, and act upon it - for example, a virtual page
may be remapped (its guest physical address changed inside the
page-table), in which case the introspection logic would update the
protection accordingly (remove EPT hook on the old gpa, and place a new
EPT hook on the new gpa). In other cases, the modification may be of no
interest to the introspection engine - for example, the accessed/dirty
bits may be cleared by the operating system or the accessed/dirty bits
may be set by the CPU page walker.
In our tests we discovered that the vast majority of guest page-table
modifications fall in the second category (especially on Windows 10 RS4
x64 - more than 95% of ALL the page-table modifications are irrelevant to
us) - they are of no interest to the introspection logic, but they
trigger a very costly EPT violation nonetheless. Therefore, we decided
to make use of the new #VE & VMFUNC features in recent Intel CPUs to
accelerate the guest page-tables monitoring in the following way:
1. Each monitored page-table would be flagged as being convertible
inside the EPT, thus enabling the CPU to deliver a virtualization
exception to he guest instead of generating a traditional EPT
violation.
2. We inject a small filtering driver inside the protected guest VM,
which would intercept the virtualization exception in order to handle
guest page-table modifications.
3. We create a dedicated EPT view (altp2m) for the in-guest agent, which
would isolate the agent from the rest of the operating system; the
agent will switch in and out of the protected EPT view via the VMFUNC
instruction placed inside a trampoline page, thus making the agent
immune to malicious code inside the guest.
This way, all the page-table accesses would generate a
virtualization-exception inside the guest instead of a costly EPT
violation; the #VE agent would emulate and analyse the modification, and
decide whether it is relevant for the main introspection logic; if it is
relevant, it would do a VMCALL and notify the introspection engine
about the modification; otherwise, it would resume normal instruction
execution, thus avoiding a very costly VM exit.
Signed-off-by: Adrian Pop
---
Changes in v2:
- remove the "__get_vcpu()" helper
---
tools/libxc/xc_altp2m.c | 1 -
xen/arch/x86/hvm/hvm.c | 19 ++-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index ce4a1e4d60..528e929d7a 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -68,7 +68,6 @@ int xc_altp2m_set_domain_state(xc_interface *handle, uint32_t
dom, bool state)
return rc;
}
-/* This is a bit odd to me that it acts on current.. */
int xc_altp2m_set_vcpu_enable_notify(xc_interface *handle, uint32_t domid,
uint32_t vcpuid, xen_pfn_t gfn)
{
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 72c51faecb..49c3bbee94 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4533,8 +4533,7 @@ static int do_altp2m_op(
return -EOPNOTSUPP;
}
-d = ( a.cmd != HVMOP_altp2m_vcpu_enable_notify ) ?
-rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
+d = rcu_lock_domain_by_any_id(a.domain);
if ( d == NULL )
return -ESRCH;
@@ -4605,26 +4604,28 @@ static int do_altp2m_op(
case HVMOP_altp2m_vcpu_enable_notify:
{
-struct vcpu *curr = current;
+struct vcpu *v;
p2m_type_t p2mt;
-if ( a.u.enable_notify.pad || a.domain != DOMID_SELF ||
- a.u.enable_notify.vcpu_id != curr->vcpu_id )
+if ( a.u.enable_notify.pad ||
+ a.u.enable_notify.vcpu_id >= d->max_vcpus )
{
rc = -EINVAL;
break;
}
-if ( !gfn_eq(vcpu_altp2m(curr).veinfo_gfn, INVALID_GFN) ||
- mfn_eq(get_gfn_query_unlocked(curr->domain,
+v = d->vcpu[a.u.enable_notify.vcpu_id];
+
+if ( !gfn_eq(vcpu_altp2m(v).veinfo_gfn, INVALID_GFN) ||
+ mfn_eq(get_gfn_query_unlocked(v->domain,
a.u.enable_notify.gfn, ), INVALID_MFN) )
{
rc = -EINVAL;
break;
}
-vcpu_altp2m(curr).veinfo_gfn = _gfn(a.u.enable_notify.gfn);
-altp2m_vcpu_update_vmfunc_ve(curr);
+vcpu_altp2m(v).veinfo_gfn = _gfn(a.u.enable_notify.gfn);
+altp2m_vcpu_update_vmfunc_ve(v);
break;
}
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
[Xen-devel] [xen-unstable-smoke test] 127234: regressions - FAIL
flight 127234 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127234/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 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 a9a2a761f75126d908612c64fabe6adde2b6d2b9
baseline version:
xen 16bbf8e7b39b50457bb2f6547f166bd54d50e4cd
Last test of basis 127212 2018-09-03 13:00:29 Z0 days
Failing since127215 2018-09-03 16:00:27 Z0 days5 attempts
Testing same since 127219 2018-09-03 19:00:33 Z0 days4 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
Razvan Cojocaru
Roger Pau Monné
Tim Deegan
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
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 a9a2a761f75126d908612c64fabe6adde2b6d2b9
Author: Andrew Cooper
Date: Wed Aug 1 13:48:33 2018 +
x86/hvm: Fix mapping corner case during task switching
hvm_map_entry() can fail for a number of reasons, including for a misaligned
LDT/GDT access which crosses a 4K boundary. Architecturally speaking, this
should be fixed, but Long Mode doesn't support task switches, and no 32bit
OS
is going to misalign its LDT/GDT base, which is why this task isn't very
high
on the TODO list.
However, the hvm_map_fail error label returns failure without raising an
exception, which interferes with hvm_task_switch()'s exception tracking, and
can cause it to finish and return to guest context as if the task switch had
completed successfully.
Resolve this corner case by folding all the failure paths together, which
causes an hvm_map_entry() failure to result in #TS[SEL]. hvm_unmap_entry()
copes fine with a NULL pointer so can be called unconditionally.
In practice, this is just a latent corner case as all hvm_map_entry()
failures
crash the domain, but it should be fixed nevertheless.
Finally, rename hvm_load_segment_selector() to task_switch_load_seg() to
avoid
giving the impression that it is usable for general segment loading.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit 1f0598a1beb6bbaa838dec4f321af543d3b96c7a
Author: Andrew Cooper
Date: Wed Jan 24 16:43:55 2018 +
x86/mm: Drop {HAP,SHADOW}_ERROR() wrappers
Unlike the PRINTK/DEBUG wrappers, these go straight out to the console,
rather
than ending up in the debugtrace buffer.
A number of these users are followed by domain_crash(), and future changes
will want to combine the printk() into the domain_crash() call. Expand
these
wrappers in place, using XENLOG_ERR before a BUG(), and XENLOG_G_ERR before
a
domain_crash().
Perfom some %pv/PRI_mfn/etc cleanup while modifying the invocations, and
explicitly drop some calls which are unnecessary (bad shadow op, and the
empty
stubs for incorrect sh_map_and_validate_gl?e() calls).
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Tim Deegan
commit 4f9b0dbb33aca70cdb61c2988866cbedb4181702
Author: Andrew Cooper
Date: Mon Sep 3 17:45:52 2018 +0100
xen/x86: Ignore the automatically generated
[Xen-devel] [seabios test] 127226: tolerable FAIL - PUSHED
flight 127226 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/127226/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 126467 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 126467 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 126467 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 126467 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-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: seabios e4db8c6db9356358d6a34caa19166ae72337e0cc baseline version: seabios 7961917493baedb0aafd41d88029ed610d0c433f Last test of basis 126467 2018-08-23 14:40:38 Z 11 days Testing same since 127226 2018-09-03 21:40:45 Z0 days1 attempts People who touched revisions under test: Kevin O'Connor jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictpass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/seabios.git 7961917..e4db8c6 e4db8c6db9356358d6a34caa19166ae72337e0cc -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 127228: regressions - FAIL
flight 127228 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127228/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 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 a9a2a761f75126d908612c64fabe6adde2b6d2b9
baseline version:
xen 16bbf8e7b39b50457bb2f6547f166bd54d50e4cd
Last test of basis 127212 2018-09-03 13:00:29 Z0 days
Failing since127215 2018-09-03 16:00:27 Z0 days4 attempts
Testing same since 127219 2018-09-03 19:00:33 Z0 days3 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
Razvan Cojocaru
Roger Pau Monné
Tim Deegan
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
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 a9a2a761f75126d908612c64fabe6adde2b6d2b9
Author: Andrew Cooper
Date: Wed Aug 1 13:48:33 2018 +
x86/hvm: Fix mapping corner case during task switching
hvm_map_entry() can fail for a number of reasons, including for a misaligned
LDT/GDT access which crosses a 4K boundary. Architecturally speaking, this
should be fixed, but Long Mode doesn't support task switches, and no 32bit
OS
is going to misalign its LDT/GDT base, which is why this task isn't very
high
on the TODO list.
However, the hvm_map_fail error label returns failure without raising an
exception, which interferes with hvm_task_switch()'s exception tracking, and
can cause it to finish and return to guest context as if the task switch had
completed successfully.
Resolve this corner case by folding all the failure paths together, which
causes an hvm_map_entry() failure to result in #TS[SEL]. hvm_unmap_entry()
copes fine with a NULL pointer so can be called unconditionally.
In practice, this is just a latent corner case as all hvm_map_entry()
failures
crash the domain, but it should be fixed nevertheless.
Finally, rename hvm_load_segment_selector() to task_switch_load_seg() to
avoid
giving the impression that it is usable for general segment loading.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit 1f0598a1beb6bbaa838dec4f321af543d3b96c7a
Author: Andrew Cooper
Date: Wed Jan 24 16:43:55 2018 +
x86/mm: Drop {HAP,SHADOW}_ERROR() wrappers
Unlike the PRINTK/DEBUG wrappers, these go straight out to the console,
rather
than ending up in the debugtrace buffer.
A number of these users are followed by domain_crash(), and future changes
will want to combine the printk() into the domain_crash() call. Expand
these
wrappers in place, using XENLOG_ERR before a BUG(), and XENLOG_G_ERR before
a
domain_crash().
Perfom some %pv/PRI_mfn/etc cleanup while modifying the invocations, and
explicitly drop some calls which are unnecessary (bad shadow op, and the
empty
stubs for incorrect sh_map_and_validate_gl?e() calls).
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Tim Deegan
commit 4f9b0dbb33aca70cdb61c2988866cbedb4181702
Author: Andrew Cooper
Date: Mon Sep 3 17:45:52 2018 +0100
xen/x86: Ignore the automatically generated
[Xen-devel] [linux-next test] 127206: regressions - FAIL
flight 127206 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/127206/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 127148 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 127148 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 127148 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 127148 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 127148 test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 127148 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 127148 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 127148 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 127148 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 127148 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 127148 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 127148 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 127148 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 127148 test-amd64-amd64-examine 8 reboot fail REGR. vs. 127148 build-arm64-pvops 6 kernel-build fail REGR. vs. 127148 test-armhf-armhf-examine 8 reboot fail REGR. vs. 127148 test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 127148 test-armhf-armhf-libvirt 7 xen-boot fail REGR. vs. 127148 test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 127148 test-armhf-armhf-xl-arndale 7 xen-boot fail REGR. vs. 127148 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 7 xen-boot fail REGR. vs. 127148 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow210 debian-di-install fail blocked in 127148 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail blocked in 127148 test-amd64-amd64-xl-multivcpu 12 guest-startfail blocked in 127148 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail blocked in 127148 test-amd64-amd64-xl-rtds 12 guest-start fail blocked in 127148 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail blocked in 127148 test-amd64-i386-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail blocked in 127148 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail like 127148 test-amd64-amd64-rumprun-amd64 12 guest-start fail like 127148 test-amd64-i386-rumprun-i386 12 guest-start fail like 127148 test-amd64-amd64-xl-shadow 12 guest-start fail like 127148 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-installfail like 127148 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail like 127148 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail like 127148 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 127148 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail like 127148 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail like 127148 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail like 127148 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-installfail like 127148 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail like 127148 test-amd64-i386-freebsd10-i386 11 guest-start fail like 127148 test-amd64-amd64-xl-xsm 12 guest-start fail like 127148 test-amd64-amd64-xl 12 guest-start fail like 127148 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail like 127148 test-amd64-i386-xl 12 guest-start fail like 127148 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail like 127148 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail like 127148 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-installfail like 127148 test-amd64-i386-xl-xsm 12 guest-start fail like 127148 test-amd64-amd64-pygrub 7 xen-boot fail like 127148 test-amd64-amd64-qemuu-nested-intel 10
[Xen-devel] [xen-unstable test] 127205: trouble: broken/fail/pass
flight 127205 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/127205/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xen-freebsd broken build-amd64-xen-freebsd 5 host-install(5)broken REGR. vs. 126854 Tests which are failing intermittently (not blocking): test-amd64-amd64-examine 4 memdisk-try-append fail pass in 127149 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 126854 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 126854 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 126854 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 126854 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 126854 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 126854 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 126854 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 126854 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 126854 build-amd64-xen-xsm-freebsd 7 xen-build-freebsdfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-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-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 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-amd64-i386-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-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen f04955e18502035121776f6e09d83ae5a36c773c baseline version: xen 36e29dd9e580cb0f847f5ac1e72afdb5febe3e99 Last test of basis 126854 2018-08-28 12:14:33 Z6 days Failing since126952 2018-08-29 15:25:50 Z5 days6 attempts Testing same since 127012 2018-08-30 23:16:20 Z4 days5 attempts People who touched revisions under test: Andrew Cooper Daniel De Graaf Gopalasetty, Manoj Jan Beulich Julien Grall
Re: [Xen-devel] [xen-unstable-smoke test] 127225: regressions - FAIL
On 03/09/18 23:41, osstest service owner wrote: > flight 127225 xen-unstable-smoke real [real] > http://logs.test-lab.xenproject.org/osstest/logs/127225/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. > vs. 127212 Sep 3 21:46:47.330655 (XEN) MMIO emulation failed (1): d1v0 32bit @ :0010 -> 55 89 e5 53 83 ec 10 8b 55 0c b8 20 02 08 00 8b Sep 3 21:46:47.438712 (XEN) d1v0 Triple fault - invoking HVM shutdown action 1 Sep 3 21:46:47.438779 (XEN) *** Dumping Dom1 vcpu#0 state: *** Sep 3 21:46:47.438830 (XEN) [ Xen-4.12-unstable x86_64 debug=y Not tainted ] Sep 3 21:46:47.450737 (XEN) CPU:2 Sep 3 21:46:47.450800 (XEN) RIP::[<0010>] Sep 3 21:46:47.450850 (XEN) RFLAGS: 00010002 CONTEXT: hvm guest (d1v0) Sep 3 21:46:47.462716 (XEN) rax: rbx: 001a8000 rcx: Sep 3 21:46:47.474720 (XEN) rdx: rsi: rdi: Sep 3 21:46:47.474788 (XEN) rbp: rsp: r8: Sep 3 21:46:47.486712 (XEN) r9: r10: r11: Sep 3 21:46:47.486782 (XEN) r12: r13: r14: Sep 3 21:46:47.498720 (XEN) r15: cr0: 0011 cr4: Sep 3 21:46:47.510700 (XEN) cr3: cr2: Sep 3 21:46:47.510764 (XEN) fsb: gsb: gss: Sep 3 21:46:47.522513 (XEN) ds: es: fs: gs: ss: cs: andrew@andrew-laptop:~/xen.git$ objdump -d tools/firmware/hvmloader/hvmloader | head tools/firmware/hvmloader/hvmloader: file format elf32-i386 Disassembly of section .text: 0010 : 10: 55 push %ebp 11: 89 e5 mov %esp,%ebp 13: 53 push %ebx Sorry Roger, but your linker change has caused _start not to be at the beginning of resulting binary. The crash is caused by using the stack before a stack is set up. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 127225: regressions - FAIL
flight 127225 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127225/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 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 a9a2a761f75126d908612c64fabe6adde2b6d2b9
baseline version:
xen 16bbf8e7b39b50457bb2f6547f166bd54d50e4cd
Last test of basis 127212 2018-09-03 13:00:29 Z0 days
Failing since127215 2018-09-03 16:00:27 Z0 days3 attempts
Testing same since 127219 2018-09-03 19:00:33 Z0 days2 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
Razvan Cojocaru
Roger Pau Monné
Tim Deegan
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
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 a9a2a761f75126d908612c64fabe6adde2b6d2b9
Author: Andrew Cooper
Date: Wed Aug 1 13:48:33 2018 +
x86/hvm: Fix mapping corner case during task switching
hvm_map_entry() can fail for a number of reasons, including for a misaligned
LDT/GDT access which crosses a 4K boundary. Architecturally speaking, this
should be fixed, but Long Mode doesn't support task switches, and no 32bit
OS
is going to misalign its LDT/GDT base, which is why this task isn't very
high
on the TODO list.
However, the hvm_map_fail error label returns failure without raising an
exception, which interferes with hvm_task_switch()'s exception tracking, and
can cause it to finish and return to guest context as if the task switch had
completed successfully.
Resolve this corner case by folding all the failure paths together, which
causes an hvm_map_entry() failure to result in #TS[SEL]. hvm_unmap_entry()
copes fine with a NULL pointer so can be called unconditionally.
In practice, this is just a latent corner case as all hvm_map_entry()
failures
crash the domain, but it should be fixed nevertheless.
Finally, rename hvm_load_segment_selector() to task_switch_load_seg() to
avoid
giving the impression that it is usable for general segment loading.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit 1f0598a1beb6bbaa838dec4f321af543d3b96c7a
Author: Andrew Cooper
Date: Wed Jan 24 16:43:55 2018 +
x86/mm: Drop {HAP,SHADOW}_ERROR() wrappers
Unlike the PRINTK/DEBUG wrappers, these go straight out to the console,
rather
than ending up in the debugtrace buffer.
A number of these users are followed by domain_crash(), and future changes
will want to combine the printk() into the domain_crash() call. Expand
these
wrappers in place, using XENLOG_ERR before a BUG(), and XENLOG_G_ERR before
a
domain_crash().
Perfom some %pv/PRI_mfn/etc cleanup while modifying the invocations, and
explicitly drop some calls which are unnecessary (bad shadow op, and the
empty
stubs for incorrect sh_map_and_validate_gl?e() calls).
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Tim Deegan
commit 4f9b0dbb33aca70cdb61c2988866cbedb4181702
Author: Andrew Cooper
Date: Mon Sep 3 17:45:52 2018 +0100
xen/x86: Ignore the automatically generated
Re: [Xen-devel] [RFC PATCH v2 02/17] libxl: Add "stubdomain_version" to domain_build_info.
On Thu, Aug 09, 2018 at 10:25:42AM +0100, Wei Liu wrote: > On Tue, Aug 07, 2018 at 04:16:07AM +0200, Marek Marczykowski-Górecki wrote: > > From: Eric Shelton > > > > This enum gives the ability to select between a MiniOS-based QEMU > > traditional stub domain and a Linux-based QEMU upstream stub domain. To > > use the Linux-based stubdomain, the following two lines should be > > included in the appropriate xl.cfg file: > > > > device_model_version="qemu-xen" > > device_model_stubdomain_override=1 > > > > To use the MiniOS-based stubdomain, the following is used instead: > > > > device_model_version="qemu-xen-traditional" > > device_model_stubdomain_override=1 > > > Where is stubomd_version= ? Don't you want to expose such option in xl.cfg? Actually, with patch 04/17 you can set explicit stubdomain path, so stubdomain_version is only another way (redundant to device_model_version) to signal what protocol to communicate with stubdomain should be used. Right now each qemu version have only one stubdomain protocol: - qemu-xen-traditional - "mini os" one - qemu-xen - "linux" one - see cover letter Anyway, I can add stubdomain_version to 08/17 "xl: add stubdomain related options to xl config parser" patch. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 75160: tolerable FAIL
This run is configured for baseline tests only. flight 75160 ovmf real [real] http://osstest.xensource.com/osstest/logs/75160/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75158 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75158 version targeted for testing: ovmf e3b9ab433aaccffdcc71c4af286ac352d4ce7c20 baseline version: ovmf b8bcaafb39e8860a1fb672d75bb6f7bbdceb28bd Last test of basis75158 2018-09-03 03:29:06 Z0 days Testing same since75160 2018-09-03 20:50:28 Z0 days1 attempts People who touched revisions under test: Bob Feng Feng, Bob C Ruiyu Ni Star Zeng Zhaozh1x ZhiqiangX Zhao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.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. commit e3b9ab433aaccffdcc71c4af286ac352d4ce7c20 Author: Star Zeng Date: Wed Aug 29 11:08:25 2018 +0800 MdeModulePkg DxeCore: Handle multiple FV images in one FV file REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1131 PI spec and BaseTools support to generate multiple FV images in one FV file. This patch is to update DxeCore to handle the case. Cc: Liming Gao Cc: Jiewen Yao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng Reviewed-by: Liming Gao commit 0e042d0ad76157ac9bad17bb4e1ff2919ca0d8f4 Author: Star Zeng Date: Wed Aug 29 11:08:09 2018 +0800 MdeModulePkg PeiCore: Handle multiple FV images in one FV file REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1131 PI spec and BaseTools support to generate multiple FV images in one FV file. This patch is to update PeiCore to handle the case. Cc: Liming Gao Cc: Jiewen Yao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng Reviewed-by: Liming Gao commit 374168ae651fabcb77a0b9d2e55ca80b46630dbb Author: Ruiyu Ni Date: Fri Aug 31 16:29:20 2018 +0800 UefiCpuPkg/CpuExceptionHandlerLib: Avoid calling PEI services from AP When an exception happens in AP, system hangs at GetPeiServicesTablePointer(), complaining the PeiServices retrieved from memory before IDT is NULL. Due to the following commit: c563077a380437c114aba4c95be65eb963ebc1f3 * UefiCpuPkg/MpInitLib: Avoid calling PEI services from AP the IDT used by AP no longer preserve PeiServices pointer in the very beginning. But the implementation of PeiExceptionHandlerLib still assumes the PeiServices pointer is there, so the assertion happens. The patch fixes the exception handler library to not call PEI services from AP. The patch duplicates the #0 exception stub header in an allocated pool but with extra 4-byte/8-byte to store the exception handler data which was originally stored in HOB. When AP exception happens, the code gets the exception handler data from the exception handler for #0. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Cc: Jian J Wang Reviewed-by: Fan Jeff commit 87a9dd0d15631fdbd8c1cce65fa1f3fc1a48beff Author: Ruiyu Ni Date: Fri Aug 31 15:30:26 2018 +0800 CpuExceptionHandlerLib: Add comments to make code more readable Today's implementation of handling HOOK_BEFORE and HOOK_AFTER is a bit complex. More comments is better. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Cc: Fan Jeff Reviewed-by: Jian J Wang commit 4cf022f2f11fc3cd12ab5dd24e5ae74f541bac48 Author: Feng, Bob C Date: Tue Aug 28 18:22:45 2018 +0800 BaseTools: Fixed the PcdValue trailing zero issue. 1. Not append
[Xen-devel] [xen-unstable-smoke test] 127219: regressions - FAIL
flight 127219 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127219/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
127212
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 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 a9a2a761f75126d908612c64fabe6adde2b6d2b9
baseline version:
xen 16bbf8e7b39b50457bb2f6547f166bd54d50e4cd
Last test of basis 127212 2018-09-03 13:00:29 Z0 days
Failing since127215 2018-09-03 16:00:27 Z0 days2 attempts
Testing same since 127219 2018-09-03 19:00:33 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Jan Beulich
Razvan Cojocaru
Roger Pau Monné
Tim Deegan
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
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 a9a2a761f75126d908612c64fabe6adde2b6d2b9
Author: Andrew Cooper
Date: Wed Aug 1 13:48:33 2018 +
x86/hvm: Fix mapping corner case during task switching
hvm_map_entry() can fail for a number of reasons, including for a misaligned
LDT/GDT access which crosses a 4K boundary. Architecturally speaking, this
should be fixed, but Long Mode doesn't support task switches, and no 32bit
OS
is going to misalign its LDT/GDT base, which is why this task isn't very
high
on the TODO list.
However, the hvm_map_fail error label returns failure without raising an
exception, which interferes with hvm_task_switch()'s exception tracking, and
can cause it to finish and return to guest context as if the task switch had
completed successfully.
Resolve this corner case by folding all the failure paths together, which
causes an hvm_map_entry() failure to result in #TS[SEL]. hvm_unmap_entry()
copes fine with a NULL pointer so can be called unconditionally.
In practice, this is just a latent corner case as all hvm_map_entry()
failures
crash the domain, but it should be fixed nevertheless.
Finally, rename hvm_load_segment_selector() to task_switch_load_seg() to
avoid
giving the impression that it is usable for general segment loading.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
commit 1f0598a1beb6bbaa838dec4f321af543d3b96c7a
Author: Andrew Cooper
Date: Wed Jan 24 16:43:55 2018 +
x86/mm: Drop {HAP,SHADOW}_ERROR() wrappers
Unlike the PRINTK/DEBUG wrappers, these go straight out to the console,
rather
than ending up in the debugtrace buffer.
A number of these users are followed by domain_crash(), and future changes
will want to combine the printk() into the domain_crash() call. Expand
these
wrappers in place, using XENLOG_ERR before a BUG(), and XENLOG_G_ERR before
a
domain_crash().
Perfom some %pv/PRI_mfn/etc cleanup while modifying the invocations, and
explicitly drop some calls which are unnecessary (bad shadow op, and the
empty
stubs for incorrect sh_map_and_validate_gl?e() calls).
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Tim Deegan
commit 4f9b0dbb33aca70cdb61c2988866cbedb4181702
Author: Andrew Cooper
Date: Mon Sep 3 17:45:52 2018 +0100
xen/x86: Ignore the automatically generated
[Xen-devel] [ovmf baseline-only test] 75158: tolerable FAIL
This run is configured for baseline tests only. flight 75158 ovmf real [real] http://osstest.xensource.com/osstest/logs/75158/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75153 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75153 version targeted for testing: ovmf b8bcaafb39e8860a1fb672d75bb6f7bbdceb28bd baseline version: ovmf 1e57188216b1bf8de3473a0e03e422815f8f53d6 Last test of basis75153 2018-09-01 03:52:02 Z2 days Testing same since75158 2018-09-03 03:29:06 Z0 days1 attempts People who touched revisions under test: Fu Siyuan jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.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. commit b8bcaafb39e8860a1fb672d75bb6f7bbdceb28bd Author: Fu Siyuan Date: Tue Aug 28 09:49:54 2018 +0800 ShellPkg: Update Ifconfig command to accept 32bit subnet mask. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Fu Siyuan Reviewed-by: Ruiyu Ni Reviewed-by: Ye Ting Reviewed-by: Wu Jiaxin Reviewed-by: Jaben Carsey commit 12ae56cf28d6a435f39a7c9c3a97185baf76f005 Author: Fu Siyuan Date: Tue Aug 28 09:48:32 2018 +0800 MdeModulePkg/Network: Add 32bit subnet mask support for IP4 PXE boot. This patch updates IP4 stack to support 32bit subnet mask in PXE boot process. When 32bit subnet mask is used, the IP4 driver couldn't use the subnet mask to determine whether destination IP address is on-link or not, so it will always try to send all the packets to the destination IP address directly first, if failed it will continue to try the default gateway. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Fu Siyuan Reviewed-by: Ye Ting Reviewed-by: Wu Jiaxin ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 127193: regressions - FAIL
flight 127193 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/127193/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 125898 test-amd64-amd64-rumprun-amd64 12 guest-startfail REGR. vs. 125898 test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 125898 test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 125898 test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 125898 test-amd64-i386-xl 12 guest-start fail REGR. vs. 125898 test-amd64-i386-xl-xsm 12 guest-start fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125898 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 125898 test-amd64-amd64-pair21 guest-start/debian fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 125898 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 125898 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 125898 test-amd64-amd64-xl 12 guest-start fail REGR. vs. 125898 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install fail REGR. vs. 125898 test-amd64-i386-pair 21 guest-start/debian fail REGR. vs. 125898 test-amd64-amd64-xl-credit2 12 guest-start fail REGR. vs. 125898 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 125898 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 125898 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 125898 test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 125898 test-amd64-amd64-examine 8 reboot fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 125898 test-amd64-amd64-amd64-pvgrub 10 debian-di-install fail REGR. vs. 125898 test-amd64-i386-xl-raw 10 debian-di-installfail REGR. vs. 125898 test-amd64-amd64-i386-pvgrub 10 debian-di-installfail REGR. vs. 125898 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install fail REGR. vs.
Re: [Xen-devel] Xen Dom0 boot failure on platform that supports ARM GICv4
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 03 September 2018 18:14
> To: Shameerali Kolothum Thodi ;
> xen-de...@lists.xen.org
> Cc: sstabell...@kernel.org; Linuxarm ; Andre
> Przywara
> Subject: Re: Xen Dom0 boot failure on platform that supports ARM GICv4
>
>
>
> On 03/09/18 17:54, Shameerali Kolothum Thodi wrote:
> > Hi Julien,
> >
> > Thanks for taking a look at this.
> >
> >> -Original Message-
> >> From: Julien Grall [mailto:julien.gr...@arm.com]
> >> Sent: 03 September 2018 17:13
> >> To: Shameerali Kolothum Thodi ;
> >> xen-de...@lists.xen.org
> >> Cc: sstabell...@kernel.org; Linuxarm ; Andre
> >> Przywara
> >> Subject: Re: Xen Dom0 boot failure on platform that supports ARM GICv4
> >>
> >>
> >>
> >> On 03/09/18 15:53, Shameerali Kolothum Thodi wrote:
> >>> Hi,
> >>
> >> Hello,
> >>
> >>> I am trying to boot xen(stable-4.11) on one of our ARM64 boards which
> >>> has support for GICv4.
> >>>
> >>> But dom0(kernel 4.18) boot fails with the below trap,
> >>>
> >>> XEN) done.
> >>> (XEN) Std. Loglevel: All
> >>> (XEN) Guest Loglevel: All
> >>> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> >>> input to Xen)
> >>> (XEN) Freed 304kB init memory.
> >>> (XEN) traps.c:2007:d0v0 HSR=0x9384 pc=0x0841af04
> >>> gva=0x0b10ffe8 gpa=0x004000aa10ffe8
> >>
> >> Which bits of Linux is trying to access the region?
> >
> > I think it is the gic_iterate_rdists() as the offset just before this is
> > ffe8, which
> is GICR_PIDR2
> >
> >>>
> >>> After a bit of debugging, it looks like, the GICR size used in
> >> vgic_v3_domain_init()
> >>> is GICv4 GICR size(256K) and this upsets the first_cpu calculations.
> >>
> >> Can you expand what you mean by upset? What's wrong with the first_cpu
> >> calculations.
> >
> > What I meant is, since this is a GICv4, the vgic_v3_hw.regions[i]->size is
> > set to
> 256K and
> > since first_cpu is calculated like,
> >
> > first_cpu += size /GICV3_GICR_SIZE;
> >
> > gets wrong as what I am seeing is,
> >
> > (XEN) frst_cpu 2
> > (XEN) first_cpu 4
> > (XEN) first_cpu 6
> > (XEN) first_cpu 8
> > (XEN) first_cpu 10
> > (XEN) first_cpu 12
> > (XEN) first_cpu 14
> > .
> > (XEN) first_cpu 192
> >
> > But the original number of CPUS are only 96. Hence I thought this is wrong.
>
> This is perfectly fine. Until recently it was not possible to know the
> number of vCPUs at domain creation. So the function is computing the
> first CPU for all the regions.
> With the recent change, it would be possible to only compute what is
> necessary.
Ah..alright. This was not clear to me.
> >>>
> >>> Since dom0 gicv3 is also an emulated one, I think the size should be
> >>> restricted to use the GICv3 GICR size(128K). I have made the below
> >>> changes and is able to boot dom0 now.
> >>>
> >>> But not sure, this is the right approach to fix the issue. Please let me
> >>> know your thoughts.
> >>>
> >>> Thanks,
> >>> Shameer
> >>>
> >>> >8-
> >>>
> >>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> >>> index b2ed0f8..bf028cc 100644
> >>> --- a/xen/arch/arm/gic-v3.c
> >>> +++ b/xen/arch/arm/gic-v3.c
> >>> @@ -1783,7 +1783,8 @@ static int __init gicv3_init(void)
> >>>reg = readl_relaxed(GICD + GICD_TYPER);
> >>>intid_bits = GICD_TYPE_ID_BITS(reg);
> >>>
> >>> -vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
> >> intid_bits);
> >>> +vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
> >>> +intid_bits, gic_dist_supports_dvis());
> >>>gicv3_init_v2();
> >>>
> >>>spin_lock_init();
> >>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> >>> index 4b42739..0f53d88 100644
> >>> --- a/xen/arch/arm/vgic-v3.c
> >>> +++ b/xen/arch/arm/vgic-v3.c
> >>> @@ -59,18 +59,21 @@ static struct {
> >>>unsigned int nr_rdist_regions;
> >>>const struct rdist_region *regions;
> >>>unsigned int intid_bits; /* Number of interrupt ID bits */
> >>> +bool dvis;
> >>>} vgic_v3_hw;
> >>>
> >>>void vgic_v3_setup_hw(paddr_t dbase,
> >>> unsigned int nr_rdist_regions,
> >>> const struct rdist_region *regions,
> >>> - unsigned int intid_bits)
> >>> + unsigned int intid_bits,
> >>> + bool dvis)
> >>>{
> >>>vgic_v3_hw.enabled = true;
> >>>vgic_v3_hw.dbase = dbase;
> >>>vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
> >>>vgic_v3_hw.regions = regions;
> >>>vgic_v3_hw.intid_bits = intid_bits;
> >>> +vgic_v3_hw.dvis = dvis;
> >>>}
> >>>
> >>>static struct vcpu *vgic_v3_irouter_to_vcpu(struct domain *d, uint64_t
> >> irouter)
> >>> @@ -1673,6 +1676,9 @@ static int vgic_v3_domain_init(struct domain *d)
> >>>{
> >>>paddr_t size = vgic_v3_hw.regions[i].size;
>
[Xen-devel] [xen-unstable-smoke test] 127215: regressions - FAIL
flight 127215 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/127215/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 127212 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 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 09b3907f93fe023ebca809c9f706f3d022801dce baseline version: xen 16bbf8e7b39b50457bb2f6547f166bd54d50e4cd Last test of basis 127212 2018-09-03 13:00:29 Z0 days Testing same since 127215 2018-09-03 16:00:27 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Razvan Cojocaru Roger Pau Monné jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 fail 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 09b3907f93fe023ebca809c9f706f3d022801dce Author: Roger Pau Monné Date: Mon Sep 3 17:54:12 2018 +0200 The hvmloader binary generated when using LLVM LD doesn't work properly and seems to get stuck while trying to generate and load the ACPI tables. This is caused by the layout of the binary when linked with LLVM LD. LLVM LD has a different default linker script that GNU LD, and the resulting hvmloader binary is slightly different: LLVM LD: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x34 0x000ff034 0x000ff034 0x00060 0x00060 R 0x4 LOAD 0x00 0x000ff000 0x000ff000 0x38000 0x38000 RWE 0x1000 GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0 GNU LD: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x80 0x0010 0x0010 0x36308 0x3fd74 RWE 0x10 GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x4 Note that in the LLVM LD case (as with GNU LD) the .text section does indeed have the address set to 0x10 as requested on the command line: [ 1] .text PROGBITS0010 001000 00dd10 00 AX 0 0 16 There's however the PHDR which is not present when using GNU LD. Fix this by using a very simple linker script that generates the same binary regardless of whether LLVM or GNU LD is used. By using a linker script the usage of -Ttext can also be avoided by placing the desired .text load address directly in the linker script. Signed-off-by: Roger Pau Monné Reviewed-by: Wei Liu Acked-by: Jan Beulich commit 936b77255269b3b9b5685d565550e77d5080ac81 Author: Jan Beulich Date: Mon Sep 3 17:51:40 2018 +0200 x86/boot: silence MADT table entry logging Logging disabled LAPIC / x2APIC entries with invalid local APIC IDs (ones having "broadcast" meaning when used) isn't very useful, and can be quite noisy on larger systems. Suppress their logging unless opt_cpu_info is true. Signed-off-by: Jan Beulich Acked-by: Andrew Cooper commit 3f2002614af51dfd507168a1696658bac91155ce Author: Jan Beulich Date: Mon Sep 3 17:50:10 2018 +0200 x86: assorted array_index_nospec() insertions Don't chance having Spectre v1 (including BCBS) gadgets. In some of the cases the insertions are more of
Re: [Xen-devel] [PATCH v2 4/6] x86emul: clean up AVX2 insn use in test harness
On 29/08/18 15:24, Jan Beulich wrote: > Drop the pretty pointless conditionals from code testing AVX insns and > properly use AVX2 mnemonics in code testing AVX2 insns (the test harness > is already requiring sufficiently new a compiler/assembler). > > 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 v2 3/6] x86emul: support AVX512 opmask insns
On 29/08/18 15:24, Jan Beulich wrote:
> These are all VEX encoded, so the EVEX decoding logic continues to
> remain unused at this point.
>
> The new testcase is deliberately coded in assembly, as a C one would
> have become almost unreadable due to the overwhelming amount of
> __builtin_...() that would need to be used. After all the compiler has
> no underlying type (yet) that could be operated on without builtins,
> other than the vector types used for "normal" SIMD insns.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -6002,6 +6023,60 @@ x86_emulate(
> dst.val = src.val;
> break;
>
> +case X86EMUL_OPC_VEX(0x0f, 0x4a):/* kadd{w,q} k,k,k */
> +if ( !vex.w )
> +host_and_vcpu_must_have(avx512dq);
Why is this kadd handled differently? As far as I can tell from the
manual, its encoding looks to be consistent.
I'm afraid that I'm going to have to stare at the manual a bit more
before I can review the rest of this patch.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 04/13] optee: add OP-TEE mediator skeleton
Hi Julien,
On 03.09.18 20:38, Julien Grall wrote:
Hi Volodymyr,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destuction and forward all known
s/destuction/destruction/
calls.
This is all what is needed for Dom0 to work with OP-TEE as long
as Dom0 shares 1:1 mapped pages with OP-TEE. Any attempt to call
OP-TEE from DomU will fail and can lead to spectacular results.
Shall we expect fireworks? :).
I tried couple of time, but with no success :)
Anyway, I think this is a call for forbidding DomU access until it is
supported. This also has the benefits to allow merging Dom0 support for
OP-TEE without the rest.
Some time ago you said that I can't be sure that Dom0 is 1:1 mapped,
because of grant refs. So, actually, any access should be forbidden. I
can omit
REGISTER_TEE_MEDIATOR(optee, "OP-TEE", _ops);
till the very last patch in the series.
But then it would not compile, because optee_ops is the static struct...
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/Kconfig | 4 ++
xen/arch/arm/tee/Makefile | 1 +
xen/arch/arm/tee/optee.c | 134
xen/include/asm-arm/tee/optee_smc.h | 50 ++
4 files changed, 189 insertions(+)
create mode 100644 xen/arch/arm/tee/optee.c
diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
index e69de29..5b829db 100644
--- a/xen/arch/arm/tee/Kconfig
+++ b/xen/arch/arm/tee/Kconfig
@@ -0,0 +1,4 @@
+config OPTEE
+ bool "Enable OP-TEE mediator"
+ default n
+ depends on TEE
diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
index c54d479..982c879 100644
--- a/xen/arch/arm/tee/Makefile
+++ b/xen/arch/arm/tee/Makefile
@@ -1 +1,2 @@
obj-y += tee.o
+obj-$(CONFIG_OPTEE) += optee.o
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
new file mode 100644
index 000..7bb84d9
--- /dev/null
+++ b/xen/arch/arm/tee/optee.c
@@ -0,0 +1,134 @@
+/*
+ * xen/arch/arm/tee/optee.c
+ *
+ * OP-TEE mediator
+ *
+ * Volodymyr Babchuk
+ * Copyright (c) 2018 EPAM Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static bool optee_probe(void)
+{
+ struct dt_device_node *node;
+ struct arm_smccc_res resp;
+
+ /* Check for entry in dtb */
+ node = dt_find_compatible_node(NULL, NULL, "linaro,optee-tz");
+ if ( !node )
+ return false;
+
+ /* Check UID */
+ arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END), );
+
+ if ( resp.a0 != OPTEE_MSG_UID_0 ||
+ resp.a1 != OPTEE_MSG_UID_1 ||
+ resp.a2 != OPTEE_MSG_UID_2 ||
+ resp.a3 != OPTEE_MSG_UID_3 )
I would be extra cautious with the sign-extension here. It would be
better to follow the spec regarding UUID by casting resp.a0 & co to 32-bit.
+ return false;
+
+ return true;
+}
+
+static int optee_enable(struct domain *d)
+{
+ struct arm_smccc_res resp;
+
+ arm_smccc_smc(OPTEE_SMC_VM_CREATED, d->domain_id + 1, 0, 0, 0, 0,
0, 0,
+ );
+ if ( resp.a0 != OPTEE_SMC_RETURN_OK ) {
+ gprintk(XENLOG_WARNIREGISTER_TEE_MEDIATOR(optee, "OP-TEE", _ops);NG, "OP-TEE don't want to support domain:
%d\n",
This message is slightly odd. It would be better to say:
"Unable to create OP-TEE client: rc=%d\n".
+ (uint32_t)resp.a0);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void forward_call(struct cpu_user_regs *regs)
+{
+ struct arm_smccc_res resp;
+
+ arm_smccc_smc(get_user_reg(regs, 0),
+ get_user_reg(regs, 1),
+ get_user_reg(regs, 2),
+ get_user_reg(regs, 3),
+ get_user_reg(regs, 4),
+ get_user_reg(regs, 5),
+ get_user_reg(regs, 6),
+ /* client id 0 is reserved for hypervisor itself */
+ current->domain->domain_id + 1,
I would prefer if the client ID is encoded in a macro. So this could be
re-used
Something like
#define OPTEE_CLIENT_ID(domain) (domain->domain_id + 1)
?
+ );
+
+ set_user_reg(regs, 0, resp.a0);
+ set_user_reg(regs, 1, resp.a1);
+ set_user_reg(regs, 2, resp.a2);
+ set_user_reg(regs, 3, resp.a3);
+ set_user_reg(regs, 4, 0);
+ set_user_reg(regs, 5, 0);
+ set_user_reg(regs, 6, 0);
+ set_user_reg(regs, 7, 0);
+}
+
+static void optee_domain_destroy(struct domain *d)
+{
+ struct arm_smccc_res resp;
+
+ /* At this time all domain VCPUs should be stopped */
+
+ /* Inform OP-TEE that domain is shutting down */
+ arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, d->domain_id + 1, 0, 0, 0,
0, 0, 0,
+ );
So this SMC should never fail or
Re: [Xen-devel] [PATCH v2 04/13] optee: add OP-TEE mediator skeleton
Hi Volodymyr,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destuction and forward all known
s/destuction/destruction/
calls.
This is all what is needed for Dom0 to work with OP-TEE as long
as Dom0 shares 1:1 mapped pages with OP-TEE. Any attempt to call
OP-TEE from DomU will fail and can lead to spectacular results.
Shall we expect fireworks? :).
Anyway, I think this is a call for forbidding DomU access until it is
supported. This also has the benefits to allow merging Dom0 support for
OP-TEE without the rest.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/Kconfig| 4 ++
xen/arch/arm/tee/Makefile | 1 +
xen/arch/arm/tee/optee.c| 134
xen/include/asm-arm/tee/optee_smc.h | 50 ++
4 files changed, 189 insertions(+)
create mode 100644 xen/arch/arm/tee/optee.c
diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
index e69de29..5b829db 100644
--- a/xen/arch/arm/tee/Kconfig
+++ b/xen/arch/arm/tee/Kconfig
@@ -0,0 +1,4 @@
+config OPTEE
+ bool "Enable OP-TEE mediator"
+ default n
+ depends on TEE
diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
index c54d479..982c879 100644
--- a/xen/arch/arm/tee/Makefile
+++ b/xen/arch/arm/tee/Makefile
@@ -1 +1,2 @@
obj-y += tee.o
+obj-$(CONFIG_OPTEE) += optee.o
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
new file mode 100644
index 000..7bb84d9
--- /dev/null
+++ b/xen/arch/arm/tee/optee.c
@@ -0,0 +1,134 @@
+/*
+ * xen/arch/arm/tee/optee.c
+ *
+ * OP-TEE mediator
+ *
+ * Volodymyr Babchuk
+ * Copyright (c) 2018 EPAM Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static bool optee_probe(void)
+{
+struct dt_device_node *node;
+struct arm_smccc_res resp;
+
+/* Check for entry in dtb */
+node = dt_find_compatible_node(NULL, NULL, "linaro,optee-tz");
+if ( !node )
+return false;
+
+/* Check UID */
+arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END), );
+
+if ( resp.a0 != OPTEE_MSG_UID_0 ||
+ resp.a1 != OPTEE_MSG_UID_1 ||
+ resp.a2 != OPTEE_MSG_UID_2 ||
+ resp.a3 != OPTEE_MSG_UID_3 )
I would be extra cautious with the sign-extension here. It would be
better to follow the spec regarding UUID by casting resp.a0 & co to 32-bit.
+return false;
+
+return true;
+}
+
+static int optee_enable(struct domain *d)
+{
+struct arm_smccc_res resp;
+
+arm_smccc_smc(OPTEE_SMC_VM_CREATED, d->domain_id + 1, 0, 0, 0, 0, 0, 0,
+ );
+if ( resp.a0 != OPTEE_SMC_RETURN_OK ) {
+gprintk(XENLOG_WARNING, "OP-TEE don't want to support domain: %d\n",
This message is slightly odd. It would be better to say:
"Unable to create OP-TEE client: rc=%d\n".
+(uint32_t)resp.a0);
+return -ENODEV;
+}
+
+return 0;
+}
+
+static void forward_call(struct cpu_user_regs *regs)
+{
+struct arm_smccc_res resp;
+
+arm_smccc_smc(get_user_reg(regs, 0),
+ get_user_reg(regs, 1),
+ get_user_reg(regs, 2),
+ get_user_reg(regs, 3),
+ get_user_reg(regs, 4),
+ get_user_reg(regs, 5),
+ get_user_reg(regs, 6),
+ /* client id 0 is reserved for hypervisor itself */
+ current->domain->domain_id + 1,
I would prefer if the client ID is encoded in a macro. So this could be
re-used.
+ );
+
+set_user_reg(regs, 0, resp.a0);
+set_user_reg(regs, 1, resp.a1);
+set_user_reg(regs, 2, resp.a2);
+set_user_reg(regs, 3, resp.a3);
+set_user_reg(regs, 4, 0);
+set_user_reg(regs, 5, 0);
+set_user_reg(regs, 6, 0);
+set_user_reg(regs, 7, 0);
+}
+
+static void optee_domain_destroy(struct domain *d)
+{
+struct arm_smccc_res resp;
+
+/* At this time all domain VCPUs should be stopped */
+
+/* Inform OP-TEE that domain is shutting down */
+arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, d->domain_id + 1, 0, 0, 0, 0, 0, 0,
+ );
So this SMC should never fail or even get preempted? I was kind of
expecting that it may time some time to destroy a domain.
+}
+
+static bool optee_handle_call(struct cpu_user_regs *regs)
+{
+switch ( get_user_reg(regs, 0) )
+{
+case OPTEE_SMC_CALLS_COUNT:
+case OPTEE_SMC_CALLS_UID:
+case OPTEE_SMC_CALLS_REVISION:
+case OPTEE_SMC_CALL_GET_OS_UUID:
+case OPTEE_SMC_FUNCID_GET_OS_REVISION:
+case OPTEE_SMC_ENABLE_SHM_CACHE:
+case OPTEE_SMC_DISABLE_SHM_CACHE:
+case OPTEE_SMC_GET_SHM_CONFIG:
+case
Re: [Xen-devel] [PATCH v2 01/13] arm: add generic TEE mediator framework
Hi Volodymyr, On 03/09/18 17:54, Volodymyr Babchuk wrote: This patch adds basic framework for TEE mediators. Guests can't talk to TEE directly, we need some entity that will intercept request and decide what to do with them. "TEE mediator" is a such entity. This is how it works: user can build XEN with multiple TEE mediators (see the next patches, where OP-TEE mediator is introduced). TEE mediator register self with REGISTER_TEE_MEDIATOR() macro in the same way, as device drivers use DT_DEVICE_START()/DT_DEVICE_END() macros. In runtime, during initialization, framework calls probe() function for each available mediator driver to find which TEE is installed on the platform. Then generic vSMC handler will call selected mediator when it intercept SMC/HVC that belongs to TEE OS or TEE application. Curently TEE mediator is enabled only for Dom0. NIT: s/Curently/Currently/ Signed-off-by: Volodymyr Babchuk --- Changes from v1: - Removed tee_remove() function - CONFIG_TEE depends on EXPERT - tee_domain_created() converted to tee_enable() - tee_init() is called using initcall() mechanism - tee_handle_smc() renamed to tee_handle_call() Changes from "RFC" version: - renamed CONFIG_ARM_TEE to CONFIG_TEE - changed discovery mechanism: instead of UUID mathing, TEE-specific probing is used MAINTAINERS | 6 +++ xen/arch/arm/Kconfig | 9 + xen/arch/arm/Makefile | 1 + xen/arch/arm/domain.c | 4 ++ xen/arch/arm/domain_build.c | 4 ++ xen/arch/arm/setup.c | 1 + xen/arch/arm/shutdown.c | 1 + xen/arch/arm/tee/Kconfig | 0 xen/arch/arm/tee/Makefile | 1 + xen/arch/arm/tee/tee.c| 69 xen/arch/arm/vsmc.c | 5 +++ xen/arch/arm/xen.lds.S| 7 xen/include/asm-arm/tee/tee.h | 91 +++ 13 files changed, 199 insertions(+) create mode 100644 xen/arch/arm/tee/Kconfig create mode 100644 xen/arch/arm/tee/Makefile create mode 100644 xen/arch/arm/tee/tee.c create mode 100644 xen/include/asm-arm/tee/tee.h diff --git a/MAINTAINERS b/MAINTAINERS index 1970100..605e6bd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -376,6 +376,12 @@ F: config/Stubdom.mk.in F:m4/stubdom.m4 F:stubdom/ +TEE MEDIATORS +M: Volodymyr Babchuk +S: Supported +F: xen/arch/arm/tee/ +F: xen/include/asm-arm/tee + TOOLSTACK M:Ian Jackson M:Wei Liu diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 586bc62..0968378 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -102,6 +102,13 @@ config HARDEN_BRANCH_PREDICTOR If unsure, say Y. +config TEE + bool "Enable TEE mediators support" if EXPERT = "y" + default n + help + This option enables generic TEE mediators support. It allows guests + to access real TEE via one of TEE mediators implemented in XEN. + endmenu menu "ARM errata workaround via the alternative framework" @@ -227,3 +234,5 @@ source "arch/arm/platforms/Kconfig" source "common/Kconfig" source "drivers/Kconfig" + +source "arch/arm/tee/Kconfig" diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index 37fa826..630d816 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -3,6 +3,7 @@ subdir-$(CONFIG_ARM_64) += arm64 subdir-y += platforms subdir-$(CONFIG_ARM_64) += efi subdir-$(CONFIG_ACPI) += acpi +subdir-$(CONFIG_TEE) += tee obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o obj-y += bootfdt.init.o diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 4baecc2..db5f5ef 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -32,6 +32,7 @@ #include #include #include +#include #include #include #include @@ -902,6 +903,9 @@ int domain_relinquish_resources(struct domain *d) */ domain_vpl011_deinit(d); +/* Free TEE mediator resources */ +tee_domain_destroy(d); + d->arch.relmem = RELMEM_xen; /* Fallthrough */ diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index e1c79b2..d208ec7 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include @@ -2193,6 +2194,9 @@ int __init construct_dom0(struct domain *d) set_current(saved_current); p2m_restore_state(saved_current); +/* Enable TEE */ +tee_enable(d); + discard_initial_modules(); memset(regs, 0, sizeof(*regs)); diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c index 45f3841..680356f 100644 --- a/xen/arch/arm/setup.c +++ b/xen/arch/arm/setup.c @@ -47,6 +47,7 @@ #include #include #include +#include #include #include diff --git a/xen/arch/arm/shutdown.c b/xen/arch/arm/shutdown.c index b32f07e..30c6950 100644 ---
[Xen-devel] [ovmf test] 127208: all pass - PUSHED
flight 127208 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/127208/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf e3b9ab433aaccffdcc71c4af286ac352d4ce7c20 baseline version: ovmf 374168ae651fabcb77a0b9d2e55ca80b46630dbb Last test of basis 127199 2018-09-03 06:10:50 Z0 days Testing same since 127208 2018-09-03 09:40:41 Z0 days1 attempts People who touched revisions under test: Star Zeng jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 374168ae65..e3b9ab433a e3b9ab433aaccffdcc71c4af286ac352d4ce7c20 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 02/13] domctl: add tee_op domctl
Hi,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
Currently this call used only to enable TEE support for a domain.
It is planed to extend it when there will be multiple TEE
mediators, so toolstack can determine which TEE is available
on a platform.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/domctl.c | 10 ++
xen/include/public/domctl.h | 8
2 files changed, 18 insertions(+)
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 4587c75..f128d34 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
void arch_get_domain_info(const struct domain *d,
@@ -171,6 +172,15 @@ long arch_do_domctl(struct xen_domctl *domctl, struct
domain *d,
return rc;
}
+case XEN_DOMCTL_tee_op:
+switch ( domctl->u.tee_op.cmd )
+{
+case XEN_DOMCTL_TEE_OP_ENABLE:
+return tee_enable(d);
+
+default:
+return -EINVAL;
+}
I don't think a domctl is necessary for this. You can add a flag in
xen_arch_domainconfig.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Dom0 boot failure on platform that supports ARM GICv4
On 03/09/18 17:54, Shameerali Kolothum Thodi wrote:
Hi Julien,
Thanks for taking a look at this.
-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 03 September 2018 17:13
To: Shameerali Kolothum Thodi ;
xen-de...@lists.xen.org
Cc: sstabell...@kernel.org; Linuxarm ; Andre
Przywara
Subject: Re: Xen Dom0 boot failure on platform that supports ARM GICv4
On 03/09/18 15:53, Shameerali Kolothum Thodi wrote:
Hi,
Hello,
I am trying to boot xen(stable-4.11) on one of our ARM64 boards which
has support for GICv4.
But dom0(kernel 4.18) boot fails with the below trap,
XEN) done.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 304kB init memory.
(XEN) traps.c:2007:d0v0 HSR=0x9384 pc=0x0841af04
gva=0x0b10ffe8 gpa=0x004000aa10ffe8
Which bits of Linux is trying to access the region?
I think it is the gic_iterate_rdists() as the offset just before this is ffe8,
which is GICR_PIDR2
After a bit of debugging, it looks like, the GICR size used in
vgic_v3_domain_init()
is GICv4 GICR size(256K) and this upsets the first_cpu calculations.
Can you expand what you mean by upset? What's wrong with the first_cpu
calculations.
What I meant is, since this is a GICv4, the vgic_v3_hw.regions[i]->size is set
to 256K and
since first_cpu is calculated like,
first_cpu += size /GICV3_GICR_SIZE;
gets wrong as what I am seeing is,
(XEN) frst_cpu 2
(XEN) first_cpu 4
(XEN) first_cpu 6
(XEN) first_cpu 8
(XEN) first_cpu 10
(XEN) first_cpu 12
(XEN) first_cpu 14
.
(XEN) first_cpu 192
But the original number of CPUS are only 96. Hence I thought this is wrong.
This is perfectly fine. Until recently it was not possible to know the
number of vCPUs at domain creation. So the function is computing the
first CPU for all the regions.
With the recent change, it would be possible to only compute what is
necessary.
Since dom0 gicv3 is also an emulated one, I think the size should be
restricted to use the GICv3 GICR size(128K). I have made the below
changes and is able to boot dom0 now.
But not sure, this is the right approach to fix the issue. Please let me
know your thoughts.
Thanks,
Shameer
>8-
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b2ed0f8..bf028cc 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1783,7 +1783,8 @@ static int __init gicv3_init(void)
reg = readl_relaxed(GICD + GICD_TYPER);
intid_bits = GICD_TYPE_ID_BITS(reg);
-vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
intid_bits);
+vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
+intid_bits, gic_dist_supports_dvis());
gicv3_init_v2();
spin_lock_init();
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4b42739..0f53d88 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -59,18 +59,21 @@ static struct {
unsigned int nr_rdist_regions;
const struct rdist_region *regions;
unsigned int intid_bits; /* Number of interrupt ID bits */
+bool dvis;
} vgic_v3_hw;
void vgic_v3_setup_hw(paddr_t dbase,
unsigned int nr_rdist_regions,
const struct rdist_region *regions,
- unsigned int intid_bits)
+ unsigned int intid_bits,
+ bool dvis)
{
vgic_v3_hw.enabled = true;
vgic_v3_hw.dbase = dbase;
vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
vgic_v3_hw.regions = regions;
vgic_v3_hw.intid_bits = intid_bits;
+vgic_v3_hw.dvis = dvis;
}
static struct vcpu *vgic_v3_irouter_to_vcpu(struct domain *d, uint64_t
irouter)
@@ -1673,6 +1676,9 @@ static int vgic_v3_domain_init(struct domain *d)
{
paddr_t size = vgic_v3_hw.regions[i].size;
+if (vgic_v3_hw.dvis && (size == GICV4_GICR_SIZE))
+ size = GICV3_GICR_SIZE;
vgic_v3_hw.regions is describing the regions in the layout that could
hold re-distributor. You can have multiple re-distributor per region.
The variable size holds the size of the region, not the size of the
re-distributor.
I am not sure to understand why you want to restrict the size of the
region here because GICV4_GICR_SIZE is a multiple of GICV3_GICR_SIZE. So
you should be able to fit 2 re-distributors per region.
It looks like to me the re-distributor regions are not reported
correctly or Dom0 thinks it is on GICv4. Can you provide a bit more
details on the function that cause the crash and some logs from Linux?
Ok. I added few prints along the vgic mmio read path and this is what happens
before the trap.
vgic_v3_rdistr_mmio_read()
get_vcpu_from_rdist() -->returns NULL here for 0x004000aa10ffe8 which
Re: [Xen-devel] [PATCH v2] tools/xl: refuse to set number of vcpus to 0 via xl vcpu-set
On Mon, Sep 03, 2018 at 02:59:42PM +0200, Juergen Gross wrote: > Trying to set the number of vcpus of a domain to 0 isn't refused. > We should not allow that. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/5] xen/domain: Break __domain_destroy() out of domain_create() and complete_domain_destroy()
On Mon, Sep 03, 2018 at 06:05:34PM +0100, Andrew Cooper wrote:
> On 03/09/18 18:01, Wei Liu wrote:
> > On Mon, Sep 03, 2018 at 05:58:02PM +0100, Andrew Cooper wrote:
> >> On 03/09/18 17:54, Wei Liu wrote:
> >>> On Mon, Sep 03, 2018 at 03:46:57PM +0100, Andrew Cooper wrote:
> This is the first step in making the destroy path idepotent, and using
> it in
> >>> "idempotent".
> >>>
> place of the ad-hoc cleanup paths in the create path.
>
> To begin with, the trivial free operations are broken out. The rest of
> the
> cleanup code will be moved as it is demonstrated (or made) to be
> idempotent.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC: Julien Grall
> ---
> xen/common/domain.c | 29 ++---
> 1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 43ab926..2253c2d 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -260,6 +260,23 @@ static int __init parse_extra_guest_irqs(const char
> *s)
> }
> custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>
> +/*
> + * Destroy a domain once all references to it have been dropped. Used
> either
> + * from the RCU path, or from the domain_create() error path before the
> domain
> + * is inserted into the domlist.
> + */
> +static void __domain_destroy(struct domain *d)
> +{
> +BUG_ON(!d->is_dying);
> +BUG_ON(atomic_read(>refcnt) != DOMAIN_DESTROYED);
> +
> +xfree(d->pbuf);
> >>> With this changed to XFREE here:
> >> This is the one place where it doesn't matter. d goes fully out of
> >> scope before the end of this function.
> > That's fair enough.
> >
> >>> Reviewed-by: Wei Liu
> >>>
> +
> +free_cpumask_var(d->dirty_cpumask);
> >>> On making things idempotent: this function seems to be a candidate.
> >> I don't understand. One implementation is xfree() under the hood, and
> >> the other is a no-op because no allocation took place.
> > I mean it would probably be useful to make free_cpumask_var idempotent
> > by using XFREE so multiple calls to it will not free dangling pointer.
>
> Ah - that's complicated because of the (lack of) indirection of the
> parameter.
>
> There is FREE_CPUMASK_VAR() which DTRT, but see above for why it isn't
> used. (There is a similar FREE_XENHEAP_PAGE helper).
Okay. I don't have further comments on this.
Wei.
>
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/5] xen/domain: Break __domain_destroy() out of domain_create() and complete_domain_destroy()
On 03/09/18 18:01, Wei Liu wrote:
> On Mon, Sep 03, 2018 at 05:58:02PM +0100, Andrew Cooper wrote:
>> On 03/09/18 17:54, Wei Liu wrote:
>>> On Mon, Sep 03, 2018 at 03:46:57PM +0100, Andrew Cooper wrote:
This is the first step in making the destroy path idepotent, and using it
in
>>> "idempotent".
>>>
place of the ad-hoc cleanup paths in the create path.
To begin with, the trivial free operations are broken out. The rest of the
cleanup code will be moved as it is demonstrated (or made) to be
idempotent.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/domain.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 43ab926..2253c2d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -260,6 +260,23 @@ static int __init parse_extra_guest_irqs(const char
*s)
}
custom_param("extra_guest_irqs", parse_extra_guest_irqs);
+/*
+ * Destroy a domain once all references to it have been dropped. Used
either
+ * from the RCU path, or from the domain_create() error path before the
domain
+ * is inserted into the domlist.
+ */
+static void __domain_destroy(struct domain *d)
+{
+BUG_ON(!d->is_dying);
+BUG_ON(atomic_read(>refcnt) != DOMAIN_DESTROYED);
+
+xfree(d->pbuf);
>>> With this changed to XFREE here:
>> This is the one place where it doesn't matter. d goes fully out of
>> scope before the end of this function.
> That's fair enough.
>
>>> Reviewed-by: Wei Liu
>>>
+
+free_cpumask_var(d->dirty_cpumask);
>>> On making things idempotent: this function seems to be a candidate.
>> I don't understand. One implementation is xfree() under the hood, and
>> the other is a no-op because no allocation took place.
> I mean it would probably be useful to make free_cpumask_var idempotent
> by using XFREE so multiple calls to it will not free dangling pointer.
Ah - that's complicated because of the (lack of) indirection of the
parameter.
There is FREE_CPUMASK_VAR() which DTRT, but see above for why it isn't
used. (There is a similar FREE_XENHEAP_PAGE helper).
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/5] xen/domain: Break __domain_destroy() out of domain_create() and complete_domain_destroy()
On Mon, Sep 03, 2018 at 05:58:02PM +0100, Andrew Cooper wrote:
> On 03/09/18 17:54, Wei Liu wrote:
> > On Mon, Sep 03, 2018 at 03:46:57PM +0100, Andrew Cooper wrote:
> >> This is the first step in making the destroy path idepotent, and using it
> >> in
> > "idempotent".
> >
> >> place of the ad-hoc cleanup paths in the create path.
> >>
> >> To begin with, the trivial free operations are broken out. The rest of the
> >> cleanup code will be moved as it is demonstrated (or made) to be
> >> idempotent.
> >>
> >> Signed-off-by: Andrew Cooper
> >> ---
> >> CC: Jan Beulich
> >> CC: Wei Liu
> >> CC: Roger Pau Monné
> >> CC: Stefano Stabellini
> >> CC: Julien Grall
> >> ---
> >> xen/common/domain.c | 29 ++---
> >> 1 file changed, 22 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/xen/common/domain.c b/xen/common/domain.c
> >> index 43ab926..2253c2d 100644
> >> --- a/xen/common/domain.c
> >> +++ b/xen/common/domain.c
> >> @@ -260,6 +260,23 @@ static int __init parse_extra_guest_irqs(const char
> >> *s)
> >> }
> >> custom_param("extra_guest_irqs", parse_extra_guest_irqs);
> >>
> >> +/*
> >> + * Destroy a domain once all references to it have been dropped. Used
> >> either
> >> + * from the RCU path, or from the domain_create() error path before the
> >> domain
> >> + * is inserted into the domlist.
> >> + */
> >> +static void __domain_destroy(struct domain *d)
> >> +{
> >> +BUG_ON(!d->is_dying);
> >> +BUG_ON(atomic_read(>refcnt) != DOMAIN_DESTROYED);
> >> +
> >> +xfree(d->pbuf);
> > With this changed to XFREE here:
>
> This is the one place where it doesn't matter. d goes fully out of
> scope before the end of this function.
That's fair enough.
>
> >
> > Reviewed-by: Wei Liu
> >
> >> +
> >> +free_cpumask_var(d->dirty_cpumask);
> > On making things idempotent: this function seems to be a candidate.
>
> I don't understand. One implementation is xfree() under the hood, and
> the other is a no-op because no allocation took place.
I mean it would probably be useful to make free_cpumask_var idempotent
by using XFREE so multiple calls to it will not free dangling pointer.
Wei.
>
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/x86: Ignore the automatically generated include/asm-x86/asm-macros.h
On Mon, Sep 03, 2018 at 05:48:03PM +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
Re: [Xen-devel] [PATCH] tools/xl: fix output of xl vcpu-pin dry run with smt=0
On Mon, Sep 03, 2018 at 01:26:30PM +0200, Juergen Gross wrote: > Fix another smt=0 fallout: xl -N vcpu-pin prints only parts of the > affinities as it is using the number of online cpus instead of the > maximum cpu number. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/5] xen/domain: Make rangeset_domain_destroy() idempotent
On Mon, Sep 03, 2018 at 03:47:00PM +0100, Andrew Cooper wrote: > ... and move it into the common __domain_destroy() path. > > 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
Re: [Xen-devel] [PATCH 2/5] xen/domain: Break __domain_destroy() out of domain_create() and complete_domain_destroy()
On 03/09/18 17:54, Wei Liu wrote:
> On Mon, Sep 03, 2018 at 03:46:57PM +0100, Andrew Cooper wrote:
>> This is the first step in making the destroy path idepotent, and using it in
> "idempotent".
>
>> place of the ad-hoc cleanup paths in the create path.
>>
>> To begin with, the trivial free operations are broken out. The rest of the
>> cleanup code will be moved as it is demonstrated (or made) to be idempotent.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Wei Liu
>> CC: Roger Pau Monné
>> CC: Stefano Stabellini
>> CC: Julien Grall
>> ---
>> xen/common/domain.c | 29 ++---
>> 1 file changed, 22 insertions(+), 7 deletions(-)
>>
>> diff --git a/xen/common/domain.c b/xen/common/domain.c
>> index 43ab926..2253c2d 100644
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -260,6 +260,23 @@ static int __init parse_extra_guest_irqs(const char *s)
>> }
>> custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>>
>> +/*
>> + * Destroy a domain once all references to it have been dropped. Used
>> either
>> + * from the RCU path, or from the domain_create() error path before the
>> domain
>> + * is inserted into the domlist.
>> + */
>> +static void __domain_destroy(struct domain *d)
>> +{
>> +BUG_ON(!d->is_dying);
>> +BUG_ON(atomic_read(>refcnt) != DOMAIN_DESTROYED);
>> +
>> +xfree(d->pbuf);
> With this changed to XFREE here:
This is the one place where it doesn't matter. d goes fully out of
scope before the end of this function.
>
> Reviewed-by: Wei Liu
>
>> +
>> +free_cpumask_var(d->dirty_cpumask);
> On making things idempotent: this function seems to be a candidate.
I don't understand. One implementation is xfree() under the hood, and
the other is a no-op because no allocation took place.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 4/5] xen/domain: Fold xsm_free_security_domain() paths together
On Mon, Sep 03, 2018 at 03:46:59PM +0100, Andrew Cooper wrote: > xsm_free_security_domain() is idempotent (both the dummy handler, and the > flask handler). Move it into the shared __domain_destroy() path, and drop the > INIT_xsm flag from domain_create() > > 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
Re: [Xen-devel] [PATCH 3/5] xen/domain: Call lock_profile_deregister_struct() from common code
On Mon, Sep 03, 2018 at 03:46:58PM +0100, Andrew Cooper wrote: > lock_profile_register_struct() is called from common code, but the matching > deregister was previously only called from x86 code. > > The practical upshot of this when using CONFIG_LOCK_PROFILE, destroyed domains > on ARM (and in particular, the freed page behind struct domain) remain on the > lockprofile linked list, which will become corrupt when the page is reused. > > 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 v2 13/13] lixl: arm: create optee firmware node in DT if tee=1
If TEE support is enabled with "tee=1" option in xl.cfg,
then we need to inform guest about available TEE.
Currently only OP-TEE is supported, so we'll create DT
node in a way that is expected by optee driver in linux.
Signed-off-by: Volodymyr Babchuk
---
tools/libxl/libxl_arm.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 7f1d509..6376239 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -407,6 +407,32 @@ static int make_psci_node(libxl__gc *gc, void *fdt)
return 0;
}
+static int make_optee_node(libxl__gc *gc, void *fdt)
+{
+int res;
+LOG(DEBUG, "Creating OP-TEE node in dtb");
+
+res = fdt_begin_node(fdt, "firmware");
+if (res) return res;
+
+res = fdt_begin_node(fdt, "optee");
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "linaro,optee-tz");
+if (res) return res;
+
+res = fdt_property_string(fdt, "method", "smc");
+if (res) return res;
+
+res = fdt_end_node(fdt);
+if (res) return res;
+
+res = fdt_end_node(fdt);
+if (res) return res;
+
+return 0;
+}
+
static int make_memory_nodes(libxl__gc *gc, void *fdt,
const struct xc_dom_image *dom)
{
@@ -920,6 +946,9 @@ next_resize:
if (info->arch_arm.vuart == LIBXL_VUART_TYPE_SBSA_UART)
FDT( make_vpl011_uart_node(gc, fdt, ainfo, dom) );
+if (libxl_defbool_val(info->tee))
+FDT( make_optee_node(gc, fdt));
+
if (pfdt)
FDT( copy_partial_fdt(gc, fdt, pfdt) );
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 12/13] xl: add "tee" option for xl.cfg
This boolean option controls if TEE access is enabled for the domain.
If access is enabled, xl will call xc_dom_tee_enable(...) to ask
hypervisor to enable TEE support.
Signed-off-by: Volodymyr Babchuk
---
docs/man/xl.cfg.pod.5.in| 10 ++
tools/libxl/libxl_arm.c | 30 +-
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_types.idl | 1 +
tools/xl/xl_parse.c | 1 +
5 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index b727181..eac7f2b 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -2792,6 +2792,16 @@ Currently, only the "sbsa_uart" model is supported for
ARM.
=back
+=over 4
+
+=item B
+
+Enable TEE support for the guest. Currently only OP-TEE is supported. If this
+option is enabled, xl will create guest, which can access TEE. Also
+OP-TEE node will be emitted into guest's device tree.
+
+=back
+
=head3 x86
=over 4
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index baa0d38..7f1d509 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1077,23 +1077,27 @@ int libxl__arch_build_dom_finish(libxl__gc *gc,
{
int rc = 0, ret;
-if (info->arch_arm.vuart != LIBXL_VUART_TYPE_SBSA_UART) {
-rc = 0;
-goto out;
+if (info->arch_arm.vuart == LIBXL_VUART_TYPE_SBSA_UART) {
+ret = xc_dom_vuart_init(CTX->xch,
+XEN_DOMCTL_VUART_TYPE_VPL011,
+dom->guest_domid,
+dom->console_domid,
+dom->vuart_gfn,
+>vuart_port);
+if (ret < 0) {
+rc = ERROR_FAIL;
+LOG(ERROR, "xc_dom_vuart_init failed\n");
+}
}
-ret = xc_dom_vuart_init(CTX->xch,
-XEN_DOMCTL_VUART_TYPE_VPL011,
-dom->guest_domid,
-dom->console_domid,
-dom->vuart_gfn,
->vuart_port);
-if (ret < 0) {
-rc = ERROR_FAIL;
-LOG(ERROR, "xc_dom_vuart_init failed\n");
+if (libxl_defbool_val(info->tee)) {
+ret = xc_dom_tee_enable(CTX->xch, dom->guest_domid);
+if (ret < 0) {
+rc = ERROR_FAIL;
+LOG(ERROR, "xc_dom_tee_enable failed\n");
+}
}
-out:
return rc;
}
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b7b44e2..d76a294 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -217,6 +217,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
libxl__arch_domain_build_info_acpi_setdefault(b_info);
libxl_defbool_setdefault(_info->dm_restrict, false);
+libxl_defbool_setdefault(_info->tee, false);
switch (b_info->type) {
case LIBXL_DOMAIN_TYPE_HVM:
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 4a38580..8cd35ce 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -613,6 +613,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
# Alternate p2m is not bound to any architecture or guest type, as it is
# supported by x86 HVM and ARM support is planned.
("altp2m", libxl_altp2m_mode),
+("tee", libxl_defbool),
], dir=DIR_IN,
copy_deprecated_fn="libxl__domain_build_info_copy_deprecated",
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index 971ec1b..56735ff 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -2543,6 +2543,7 @@ skip_usbdev:
}
xlu_cfg_get_defbool(config, "dm_restrict", _info->dm_restrict, 0);
+xlu_cfg_get_defbool(config, "tee", _info->tee, 0);
if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
if (!xlu_cfg_get_string (config, "vga", , 0)) {
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 11/13] libxc: add xc_dom_tee_enable(...) function
This function uses XEN_DOMCTL_tee_op domctl to enable TEE
support for a given domain.
Signed-off-by: Volodymyr Babchuk
---
tools/libxc/include/xenctrl.h | 7 +++
tools/libxc/xc_domain.c | 13 +
2 files changed, 20 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c626984..f768528 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -915,6 +915,13 @@ int xc_dom_vuart_init(xc_interface *xch,
evtchn_port_t *evtchn);
/**
+ * This function enables TEE access for a given domain.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid for which TEE should be enabled
+ */
+int xc_dom_tee_enable(xc_interface *xch, uint32_t domid);
+
+/**
* This function returns information about the XSAVE state of a particular
* vcpu of a domain. If extstate->size and extstate->xfeature_mask are 0,
* the call is considered a query to retrieve them and the buffer is not
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index f5dfadd..800bb0f 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -348,6 +348,19 @@ int xc_dom_vuart_init(xc_interface *xch,
return rc;
}
+int xc_dom_tee_enable(xc_interface *xch, uint32_t domid)
+{
+DECLARE_DOMCTL;
+
+memset(, 0, sizeof(domctl));
+
+domctl.cmd = XEN_DOMCTL_tee_op;
+domctl.domain = domid;
+domctl.u.tee_op.cmd = XEN_DOMCTL_TEE_OP_ENABLE;
+
+return do_domctl(xch, );
+}
+
int xc_domain_getinfo(xc_interface *xch,
uint32_t first_domid,
unsigned int max_doms,
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 10/13] optee: add support for RPC commands
OP-TEE can issue multiple RPC requests. We are interested mostly in
request that asks NW to allocate/free shared memory for OP-TEE
needs, becuase mediator need to do address translation in the same
way as it was done for shared buffers registered by NW.
As mediator now accesses shared command buffer, we need to shadow
it in the same way, as we shadow request buffers for STD calls.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/optee.c | 137 +++
1 file changed, 126 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 8bfcfdc..b2d795e 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -45,6 +45,7 @@ struct std_call_ctx {
struct shm_rpc {
struct list_head list;
struct optee_msg_arg *guest_arg;
+struct optee_msg_arg *xen_arg;
struct page *guest_page;
mfn_t guest_mfn;
uint64_t cookie;
@@ -303,6 +304,10 @@ static struct shm_rpc *allocate_and_map_shm_rpc(struct
domain_ctx *ctx, paddr_t
if ( !shm_rpc )
goto err;
+shm_rpc->xen_arg = alloc_xenheap_page();
+if ( !shm_rpc->xen_arg )
+goto err;
+
shm_rpc->guest_mfn = lookup_and_pin_guest_ram_addr(gaddr, NULL);
if ( mfn_eq(shm_rpc->guest_mfn, INVALID_MFN) )
@@ -324,6 +329,10 @@ static struct shm_rpc *allocate_and_map_shm_rpc(struct
domain_ctx *ctx, paddr_t
err:
atomic_dec(>shm_rpc_count);
+
+if ( shm_rpc->xen_arg )
+free_xenheap_page(shm_rpc->xen_arg);
+
xfree(shm_rpc);
return NULL;
}
@@ -346,9 +355,10 @@ static void free_shm_rpc(struct domain_ctx *ctx, uint64_t
cookie)
}
spin_unlock(>lock);
-if ( !found ) {
+if ( !found )
return;
-}
+
+free_xenheap_page(shm_rpc->xen_arg);
if ( shm_rpc->guest_arg ) {
unpin_guest_ram_addr(shm_rpc->guest_mfn);
@@ -358,6 +368,24 @@ static void free_shm_rpc(struct domain_ctx *ctx, uint64_t
cookie)
xfree(shm_rpc);
}
+static struct shm_rpc *find_shm_rpc(struct domain_ctx *ctx, uint64_t cookie)
+{
+struct shm_rpc *shm_rpc;
+
+spin_lock(>lock);
+list_for_each_entry( shm_rpc, >shm_rpc_list, list )
+{
+if ( shm_rpc->cookie == cookie )
+{
+spin_unlock(>lock);
+return shm_rpc;
+}
+}
+spin_unlock(>lock);
+
+return NULL;
+}
+
static struct shm_buf *allocate_shm_buf(struct domain_ctx *ctx,
uint64_t cookie,
int pages_cnt)
@@ -704,6 +732,28 @@ static bool copy_std_request_back(struct domain_ctx *ctx,
return true;
}
+static void handle_rpc_return(struct domain_ctx *ctx,
+ struct cpu_user_regs *regs,
+ struct std_call_ctx *call)
+{
+call->optee_thread_id = get_user_reg(regs, 3);
+call->rpc_op = OPTEE_SMC_RETURN_GET_RPC_FUNC(get_user_reg(regs, 0));
+
+if ( call->rpc_op == OPTEE_SMC_RPC_FUNC_CMD )
+{
+/* Copy RPC request from shadowed buffer to guest */
+uint64_t cookie = get_user_reg(regs, 1) << 32 | get_user_reg(regs, 2);
+struct shm_rpc *shm_rpc = find_shm_rpc(ctx, cookie);
+if ( !shm_rpc )
+{
+gprintk(XENLOG_ERR, "Can't find SHM-RPC with cookie %lx\n",
cookie);
+return;
+}
+memcpy(shm_rpc->guest_arg, shm_rpc->xen_arg,
+ OPTEE_MSG_GET_ARG_SIZE(shm_rpc->xen_arg->num_params));
+}
+}
+
static bool execute_std_call(struct domain_ctx *ctx,
struct cpu_user_regs *regs,
struct std_call_ctx *call)
@@ -715,8 +765,7 @@ static bool execute_std_call(struct domain_ctx *ctx,
optee_ret = get_user_reg(regs, 0);
if ( OPTEE_SMC_RETURN_IS_RPC(optee_ret) )
{
-call->optee_thread_id = get_user_reg(regs, 3);
-call->rpc_op = OPTEE_SMC_RETURN_GET_RPC_FUNC(optee_ret);
+handle_rpc_return(ctx, regs, call);
return true;
}
@@ -783,6 +832,74 @@ out:
return ret;
}
+
+static void handle_rpc_cmd_alloc(struct domain_ctx *ctx,
+ struct cpu_user_regs *regs,
+ struct std_call_ctx *call,
+ struct shm_rpc *shm_rpc)
+{
+if ( shm_rpc->xen_arg->params[0].attr != (OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT |
+OPTEE_MSG_ATTR_NONCONTIG) )
+{
+gprintk(XENLOG_WARNING, "Invalid attrs for shared mem buffer\n");
+return;
+}
+
+/* Last entry in non_contig array is used to hold RPC-allocated buffer */
+if ( call->non_contig[MAX_NONCONTIG_ENTRIES - 1] )
+{
+free_xenheap_pages(call->non_contig[MAX_NONCONTIG_ENTRIES - 1],
+ call->non_contig_order[MAX_NONCONTIG_ENTRIES - 1]);
+call->non_contig[MAX_NONCONTIG_ENTRIES - 1] = NULL;
+}
+
[Xen-devel] [PATCH v2 06/13] optee: add domain contexts
OP-TEE meditor needs to store per-domain context, as will be seen
in the next patches. At this moment it stores only reference to domain.
This allows us to filter out calls from domains that are not allowed
to work with OP-TEE.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/optee.c | 66
1 file changed, 66 insertions(+)
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 48bff5d..c895a99 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -19,6 +19,14 @@
#include
#include
+struct domain_ctx {
+struct list_head list;
+struct domain *domain;
+};
+
+static LIST_HEAD(domain_ctx_list);
+static DEFINE_SPINLOCK(domain_ctx_list_lock);
+
static bool optee_probe(void)
{
struct dt_device_node *node;
@@ -41,18 +49,49 @@ static bool optee_probe(void)
return true;
}
+static struct domain_ctx *find_domain_ctx(struct domain* d)
+{
+struct domain_ctx *ctx;
+
+spin_lock(_ctx_list_lock);
+
+list_for_each_entry( ctx, _ctx_list, list )
+{
+if ( ctx->domain == d )
+{
+spin_unlock(_ctx_list_lock);
+return ctx;
+}
+}
+
+spin_unlock(_ctx_list_lock);
+return NULL;
+}
+
static int optee_enable(struct domain *d)
{
struct arm_smccc_res resp;
+struct domain_ctx *ctx;
+
+ctx = xzalloc(struct domain_ctx);
+if ( !ctx )
+return -ENOMEM;
arm_smccc_smc(OPTEE_SMC_VM_CREATED, d->domain_id + 1, 0, 0, 0, 0, 0, 0,
);
if ( resp.a0 != OPTEE_SMC_RETURN_OK ) {
gprintk(XENLOG_WARNING, "OP-TEE don't want to support domain: %d\n",
(uint32_t)resp.a0);
+xfree(ctx);
return -ENODEV;
}
+ctx->domain = d;
+
+spin_lock(_ctx_list_lock);
+list_add_tail(>list, _ctx_list);
+spin_unlock(_ctx_list_lock);
+
return 0;
}
@@ -95,15 +134,36 @@ static void set_return(struct cpu_user_regs *regs,
uint32_t ret)
set_user_reg(regs, 7, 0);
}
+
static void optee_domain_destroy(struct domain *d)
{
struct arm_smccc_res resp;
+struct domain_ctx *ctx;
+bool found = false;
/* At this time all domain VCPUs should be stopped */
/* Inform OP-TEE that domain is shutting down */
arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, d->domain_id + 1, 0, 0, 0, 0, 0, 0,
);
+
+/* Remove context from the list */
+spin_lock(_ctx_list_lock);
+list_for_each_entry( ctx, _ctx_list, list )
+{
+if ( ctx->domain == d )
+{
+found = true;
+list_del(>list);
+break;
+}
+}
+spin_unlock(_ctx_list_lock);
+
+if ( !found )
+return;
+
+xfree(ctx);
}
static bool handle_exchange_capabilities(struct cpu_user_regs *regs)
@@ -141,6 +201,12 @@ static bool handle_exchange_capabilities(struct
cpu_user_regs *regs)
static bool optee_handle_call(struct cpu_user_regs *regs)
{
+struct domain_ctx *ctx;
+
+ctx = find_domain_ctx(current->domain);
+if ( !ctx )
+return false;
+
switch ( get_user_reg(regs, 0) )
{
case OPTEE_SMC_CALLS_COUNT:
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 08/13] optee: add support for RPC SHM buffers
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC requests. Problem is that initially
it has no buffer, where it can write request. So the first RPC
request it makes is special: it requests NW to allocate shared
buffer for other RPC requests. Usually this buffer is allocated
only once for every OP-TEE thread and it remains allocated all
the time until shutdown.
Mediator needs to pin this buffer(s) to make sure that domain can't
transfer it to someone else. Also it should be mapped into XEN
address space, because mediator needs to check responses from
guests.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/optee.c | 121 ++-
1 file changed, 119 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 1008eba..6d6b51d 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -21,6 +21,7 @@
#include
#define MAX_STD_CALLS 16
+#define MAX_RPC_SHMS16
/*
* Call context. OP-TEE can issue multiple RPC returns during one call.
@@ -35,11 +36,22 @@ struct std_call_ctx {
int rpc_op;
};
+/* Pre-allocated SHM buffer for RPC commands */
+struct shm_rpc {
+struct list_head list;
+struct optee_msg_arg *guest_arg;
+struct page *guest_page;
+mfn_t guest_mfn;
+uint64_t cookie;
+};
+
struct domain_ctx {
struct list_head list;
struct list_head call_ctx_list;
+struct list_head shm_rpc_list;
struct domain *domain;
atomic_t call_ctx_count;
+atomic_t shm_rpc_count;
spinlock_t lock;
};
@@ -145,8 +157,10 @@ static int optee_enable(struct domain *d)
ctx->domain = d;
INIT_LIST_HEAD(>call_ctx_list);
+INIT_LIST_HEAD(>shm_rpc_list);
atomic_set(>call_ctx_count, 0);
+atomic_set(>shm_rpc_count, 0);
spin_lock_init(>lock);
spin_lock(_ctx_list_lock);
@@ -256,11 +270,81 @@ static struct std_call_ctx *find_call_ctx(struct
domain_ctx *ctx, int thread_id)
return NULL;
}
+static struct shm_rpc *allocate_and_map_shm_rpc(struct domain_ctx *ctx,
paddr_t gaddr,
+uint64_t cookie)
+{
+struct shm_rpc *shm_rpc;
+int count;
+
+count = atomic_add_unless(>shm_rpc_count, 1, MAX_RPC_SHMS);
+if ( count == MAX_RPC_SHMS )
+return NULL;
+
+shm_rpc = xzalloc(struct shm_rpc);
+if ( !shm_rpc )
+goto err;
+
+shm_rpc->guest_mfn = lookup_and_pin_guest_ram_addr(gaddr, NULL);
+
+if ( mfn_eq(shm_rpc->guest_mfn, INVALID_MFN) )
+goto err;
+
+shm_rpc->guest_arg = map_domain_page_global(shm_rpc->guest_mfn);
+if ( !shm_rpc->guest_arg )
+{
+gprintk(XENLOG_INFO, "Could not map domain page\n");
+goto err;
+}
+shm_rpc->cookie = cookie;
+
+spin_lock(>lock);
+list_add_tail(_rpc->list, >shm_rpc_list);
+spin_unlock(>lock);
+
+return shm_rpc;
+
+err:
+atomic_dec(>shm_rpc_count);
+xfree(shm_rpc);
+return NULL;
+}
+
+static void free_shm_rpc(struct domain_ctx *ctx, uint64_t cookie)
+{
+struct shm_rpc *shm_rpc;
+bool found = false;
+
+spin_lock(>lock);
+
+list_for_each_entry( shm_rpc, >shm_rpc_list, list )
+{
+if ( shm_rpc->cookie == cookie )
+{
+found = true;
+list_del(_rpc->list);
+break;
+}
+}
+spin_unlock(>lock);
+
+if ( !found ) {
+return;
+}
+
+if ( shm_rpc->guest_arg ) {
+unpin_guest_ram_addr(shm_rpc->guest_mfn);
+unmap_domain_page_global(shm_rpc->guest_arg);
+}
+
+xfree(shm_rpc);
+}
+
static void optee_domain_destroy(struct domain *d)
{
struct arm_smccc_res resp;
struct domain_ctx *ctx;
struct std_call_ctx *call, *call_tmp;
+struct shm_rpc *shm_rpc, *shm_rpc_tmp;
bool found = false;
/* At this time all domain VCPUs should be stopped */
@@ -290,7 +374,11 @@ static void optee_domain_destroy(struct domain *d)
list_for_each_entry_safe( call, call_tmp, >call_ctx_list, list )
free_std_call_ctx(ctx, call);
+list_for_each_entry_safe( shm_rpc, shm_rpc_tmp, >shm_rpc_list, list )
+free_shm_rpc(ctx, shm_rpc->cookie);
+
ASSERT(!atomic_read(>call_ctx_count));
+ASSERT(!atomic_read(>shm_rpc_count));
xfree(ctx);
}
@@ -452,6 +540,32 @@ out:
return ret;
}
+static void handle_rpc_func_alloc(struct domain_ctx *ctx,
+ struct cpu_user_regs *regs)
+{
+paddr_t ptr = get_user_reg(regs, 1) << 32 | get_user_reg(regs, 2);
+
+if ( ptr & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1) )
+gprintk(XENLOG_WARNING, "Domain returned invalid RPC command
buffer\n");
+
+if ( ptr ) {
+uint64_t cookie = get_user_reg(regs, 4) << 32 | get_user_reg(regs, 5);
+struct shm_rpc *shm_rpc;
+
+shm_rpc = allocate_and_map_shm_rpc(ctx, ptr, cookie);
+if ( !shm_rpc )
+{
+gprintk(XENLOG_WARNING,
[Xen-devel] [PATCH v2 09/13] optee: add support for arbitrary shared memory
Shared memory is widely used by NW to communicate with
TAs in OP-TEE. NW can share part of own memory with
TA or OP-TEE core, by registering it OP-TEE, or by providing
a temporal refernce. Anyways, information about such memory
buffers are sent to OP-TEE as a list of pages. This mechanism
is descripted optee_msg.h.
Mediator should step in when NW tries to share memory with
OP-TEE for two reasons:
1. Do address translation from IPA to PA.
2. Pin domain pages till they are mapped into OP-TEE or TA
address space, so domain can't transfer this pages to
other domain or baloon out them.
Address translation is done by translate_noncontig(...) function.
It allocates new buffer from xenheap and then walks on guest
provided list of pages, translates addresses and stores PAs into
newly allocated buffer. This buffer will be provided to OP-TEE
instead of original buffer from the guest. This buffer will
be free at the end of sdandard call.
In the same time this function pins pages and stores them in
struct shm_buf object. This object will live all the time,
when given SHM buffer is known to OP-TEE. It will be freed
after guest unregisters shared buffer. At this time pages
will be unpinned.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/optee.c | 245 ++-
1 file changed, 244 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 6d6b51d..8bfcfdc 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -22,6 +22,8 @@
#define MAX_STD_CALLS 16
#define MAX_RPC_SHMS16
+#define MAX_TOTAL_SMH_BUF_PG16384
+#define MAX_NONCONTIG_ENTRIES 5
/*
* Call context. OP-TEE can issue multiple RPC returns during one call.
@@ -31,6 +33,9 @@ struct std_call_ctx {
struct list_head list;
struct optee_msg_arg *guest_arg;
struct optee_msg_arg *xen_arg;
+/* Buffer for translated page addresses, shared with OP-TEE */
+void *non_contig[MAX_NONCONTIG_ENTRIES];
+int non_contig_order[MAX_NONCONTIG_ENTRIES];
mfn_t guest_arg_mfn;
int optee_thread_id;
int rpc_op;
@@ -45,13 +50,24 @@ struct shm_rpc {
uint64_t cookie;
};
+/* Shared memory buffer for arbitrary data */
+struct shm_buf {
+struct list_head list;
+uint64_t cookie;
+int max_page_cnt;
+int page_cnt;
+struct page_info *pages[];
+};
+
struct domain_ctx {
struct list_head list;
struct list_head call_ctx_list;
struct list_head shm_rpc_list;
+struct list_head shm_buf_list;
struct domain *domain;
atomic_t call_ctx_count;
atomic_t shm_rpc_count;
+atomic_t shm_buf_pages;
spinlock_t lock;
};
@@ -158,9 +174,12 @@ static int optee_enable(struct domain *d)
ctx->domain = d;
INIT_LIST_HEAD(>call_ctx_list);
INIT_LIST_HEAD(>shm_rpc_list);
+INIT_LIST_HEAD(>shm_buf_list);
atomic_set(>call_ctx_count, 0);
atomic_set(>shm_rpc_count, 0);
+atomic_set(>shm_buf_pages, 0);
+
spin_lock_init(>lock);
spin_lock(_ctx_list_lock);
@@ -339,12 +358,76 @@ static void free_shm_rpc(struct domain_ctx *ctx, uint64_t
cookie)
xfree(shm_rpc);
}
+static struct shm_buf *allocate_shm_buf(struct domain_ctx *ctx,
+uint64_t cookie,
+int pages_cnt)
+{
+struct shm_buf *shm_buf;
+
+while(1)
+{
+int old = atomic_read(>shm_buf_pages);
+int new = old + pages_cnt;
+if ( new >= MAX_TOTAL_SMH_BUF_PG )
+return NULL;
+if ( likely(old == atomic_cmpxchg(>shm_buf_pages, old, new)) )
+break;
+}
+
+shm_buf = xzalloc_bytes(sizeof(struct shm_buf) +
+pages_cnt * sizeof(struct page *));
+if ( !shm_buf ) {
+atomic_sub(pages_cnt, >shm_buf_pages);
+return NULL;
+}
+
+shm_buf->cookie = cookie;
+shm_buf->max_page_cnt = pages_cnt;
+
+spin_lock(>lock);
+list_add_tail(_buf->list, >shm_buf_list);
+spin_unlock(>lock);
+
+return shm_buf;
+}
+
+static void free_shm_buf(struct domain_ctx *ctx, uint64_t cookie)
+{
+struct shm_buf *shm_buf;
+bool found = false;
+
+spin_lock(>lock);
+list_for_each_entry( shm_buf, >shm_buf_list, list )
+{
+if ( shm_buf->cookie == cookie )
+{
+found = true;
+list_del(_buf->list);
+break;
+}
+}
+spin_unlock(>lock);
+
+if ( !found ) {
+return;
+}
+
+for ( int i = 0; i < shm_buf->page_cnt; i++ )
+if ( shm_buf->pages[i] )
+put_page(shm_buf->pages[i]);
+
+atomic_sub(shm_buf->max_page_cnt, >shm_buf_pages);
+
+xfree(shm_buf);
+}
+
static void optee_domain_destroy(struct domain *d)
{
struct arm_smccc_res resp;
struct domain_ctx *ctx;
struct std_call_ctx *call, *call_tmp;
struct shm_rpc *shm_rpc, *shm_rpc_tmp;
+struct shm_buf *shm_buf, *shm_buf_tmp;
[Xen-devel] [PATCH v2 07/13] optee: add std call handling
Main way to communicate with OP-TEE is to issue standard SMCCC
call. "Standard" is a SMCCC term and it means that call can be
interrupted and OP-TEE can return control to NW before completing
the call.
In contranst with fast calls, where arguments and return values
are passed in registers, standard calls use shared memory. Register
pair r1,r2 holds 64-bit PA of command buffer, where all arguments
are stored and which is used to return data. OP-TEE internally
copies contents of this buffer into own secure memory before accessing
and validating any data in command buffer. This is done to make sure
that NW will not change contents of the validated parameters.
Mediator needs to do the same for number of reasons:
1. To make sure that guest will not change data after validation.
2. To translate IPAs to PAs in the command buffer (this is not done
in this patch).
3. To hide translated address from guest, so it will not be able
to do IPA->PA translation by misusing mediator.
Also mediator pins the page with original command buffer because
it will write to it later, when returning response from OP-TEE.
During standard call OP-TEE can issue multiple "RPC returns", asking
NW to do some work for OP-TEE. NW then issues special call
OPTEE_SMC_CALL_RETURN_FROM_RPC to resume handling of the original call.
Thus, mediator needs to maintain context for original standard call
during multiple SMCCC calls.
Standard call is considered complete, when returned value is
not RPC request.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/optee.c | 319 ++-
1 file changed, 316 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index c895a99..1008eba 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -12,6 +12,7 @@
*/
#include
+#include
#include
#include
#include
@@ -19,9 +20,27 @@
#include
#include
+#define MAX_STD_CALLS 16
+
+/*
+ * Call context. OP-TEE can issue multiple RPC returns during one call.
+ * We need to preserve context during them.
+ */
+struct std_call_ctx {
+struct list_head list;
+struct optee_msg_arg *guest_arg;
+struct optee_msg_arg *xen_arg;
+mfn_t guest_arg_mfn;
+int optee_thread_id;
+int rpc_op;
+};
+
struct domain_ctx {
struct list_head list;
+struct list_head call_ctx_list;
struct domain *domain;
+atomic_t call_ctx_count;
+spinlock_t lock;
};
static LIST_HEAD(domain_ctx_list);
@@ -49,6 +68,44 @@ static bool optee_probe(void)
return true;
}
+static mfn_t lookup_and_pin_guest_ram_addr(paddr_t gaddr,
+struct page_info **pg)
+{
+mfn_t mfn;
+gfn_t gfn;
+p2m_type_t t;
+struct page_info *page;
+struct domain *d = current->domain;
+
+gfn = gaddr_to_gfn(gaddr);
+mfn = p2m_lookup(d, gfn, );
+
+if ( t != p2m_ram_rw || mfn_eq(mfn, INVALID_MFN) )
+return INVALID_MFN;
+
+page = mfn_to_page(mfn);
+if ( !page )
+return INVALID_MFN;
+
+if ( !get_page(page, d) )
+return INVALID_MFN;
+
+if ( pg )
+*pg = page;
+
+return mfn;
+}
+
+static void unpin_guest_ram_addr(mfn_t mfn)
+{
+struct page_info *page;
+page = mfn_to_page(mfn);
+if ( !page )
+return;
+
+put_page(page);
+}
+
static struct domain_ctx *find_domain_ctx(struct domain* d)
{
struct domain_ctx *ctx;
@@ -87,6 +144,10 @@ static int optee_enable(struct domain *d)
}
ctx->domain = d;
+INIT_LIST_HEAD(>call_ctx_list);
+
+atomic_set(>call_ctx_count, 0);
+spin_lock_init(>lock);
spin_lock(_ctx_list_lock);
list_add_tail(>list, _ctx_list);
@@ -134,11 +195,72 @@ static void set_return(struct cpu_user_regs *regs,
uint32_t ret)
set_user_reg(regs, 7, 0);
}
+static struct std_call_ctx *allocate_std_call_ctx(struct domain_ctx *ctx)
+{
+struct std_call_ctx *call;
+int count;
+
+count = atomic_add_unless(>call_ctx_count, 1, MAX_STD_CALLS);
+if ( count == MAX_STD_CALLS )
+return NULL;
+
+call = xzalloc(struct std_call_ctx);
+if ( !call ) {
+atomic_dec(>call_ctx_count);
+return NULL;
+}
+
+call->optee_thread_id = -1;
+
+spin_lock(>lock);
+list_add_tail(>list, >call_ctx_list);
+spin_unlock(>lock);
+
+return call;
+}
+
+static void free_std_call_ctx(struct domain_ctx *ctx, struct std_call_ctx
*call)
+{
+atomic_dec(>call_ctx_count);
+
+spin_lock(>lock);
+list_del(>list);
+spin_unlock(>lock);
+
+if ( call->xen_arg )
+free_xenheap_page(call->xen_arg);
+
+if ( call->guest_arg ) {
+unmap_domain_page_global(call->guest_arg);
+unpin_guest_ram_addr(call->guest_arg_mfn);
+}
+
+xfree(call);
+}
+
+static struct std_call_ctx *find_call_ctx(struct domain_ctx *ctx, int
thread_id)
+{
+struct std_call_ctx *call;
+
+spin_lock(>lock);
+list_for_each_entry( call,
[Xen-devel] [PATCH v2 05/13] optee: add fast calls handling
Some fast SMCCC calls to OP-TEE should be handled in a special way.
Capabilities exchange should be filtered out, so only caps
known to mediator are used. Also mediator disables static SHM
memory capability, because it can't share OP-TEE memory with a domain.
Only domain can share memory with OP-TEE, so it ensures that OP-TEE
supports dynamic SHM.
Basically, static SHM is a reserved memory region which is always
mapped into OP-TEE address space. It belongs to OP-TEE. Normally,
NW is allowed to access there, so it can communicate with OP-TEE.
On other hand, dynamic SHM is NW's own memory, which it can share
with OP-TEE. OP-TEE maps this memory dynamically, when it wants to
access it.
Because mediator can't share one static SHM region with all guests,
it just disables it for all.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/optee.c | 56 +++-
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 7bb84d9..48bff5d 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -56,7 +56,7 @@ static int optee_enable(struct domain *d)
return 0;
}
-static void forward_call(struct cpu_user_regs *regs)
+static bool forward_call(struct cpu_user_regs *regs)
{
struct arm_smccc_res resp;
@@ -79,6 +79,20 @@ static void forward_call(struct cpu_user_regs *regs)
set_user_reg(regs, 5, 0);
set_user_reg(regs, 6, 0);
set_user_reg(regs, 7, 0);
+
+return resp.a0 == OPTEE_SMC_RETURN_OK;
+}
+
+static void set_return(struct cpu_user_regs *regs, uint32_t ret)
+{
+set_user_reg(regs, 0, ret);
+set_user_reg(regs, 1, 0);
+set_user_reg(regs, 2, 0);
+set_user_reg(regs, 3, 0);
+set_user_reg(regs, 4, 0);
+set_user_reg(regs, 5, 0);
+set_user_reg(regs, 6, 0);
+set_user_reg(regs, 7, 0);
}
static void optee_domain_destroy(struct domain *d)
@@ -92,6 +106,39 @@ static void optee_domain_destroy(struct domain *d)
);
}
+static bool handle_exchange_capabilities(struct cpu_user_regs *regs)
+{
+uint32_t caps;
+
+/* Filter out unknown guest caps */
+caps = get_user_reg(regs, 1);
+caps &= OPTEE_SMC_NSEC_CAP_UNIPROCESSOR;
+set_user_reg(regs, 1, caps);
+
+/* Forward call and return error (if any) back to the guest */
+if ( !forward_call(regs) )
+return true;
+
+caps = get_user_reg(regs, 1);
+
+/* Filter out unknown OP-TEE caps */
+caps &= OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM |
+OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM |
+OPTEE_SMC_SEC_CAP_DYNAMIC_SHM;
+
+/* Drop static SHM_RPC cap */
+caps &= ~OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM;
+
+/* Don't allow guests to work without dynamic SHM */
+if ( !(caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) ) {
+set_return(regs, OPTEE_SMC_RETURN_ENOTAVAIL);
+return true;
+}
+
+set_user_reg(regs, 1, caps);
+return true;
+}
+
static bool optee_handle_call(struct cpu_user_regs *regs)
{
switch ( get_user_reg(regs, 0) )
@@ -103,10 +150,17 @@ static bool optee_handle_call(struct cpu_user_regs *regs)
case OPTEE_SMC_FUNCID_GET_OS_REVISION:
case OPTEE_SMC_ENABLE_SHM_CACHE:
case OPTEE_SMC_DISABLE_SHM_CACHE:
+forward_call(regs);
+return true;
case OPTEE_SMC_GET_SHM_CONFIG:
+/* No static SHM available for guests */
+set_return(regs, OPTEE_SMC_RETURN_ENOTAVAIL);
+return true;
case OPTEE_SMC_EXCHANGE_CAPABILITIES:
+return handle_exchange_capabilities(regs);
case OPTEE_SMC_CALL_WITH_ARG:
case OPTEE_SMC_CALL_RETURN_FROM_RPC:
+/* TODO: Add proper handling for this calls */
forward_call(regs);
return true;
default:
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 04/13] optee: add OP-TEE mediator skeleton
Add very basic OP-TEE mediator. It can probe for OP-TEE presence,
tell it about domain creation/destuction and forward all known
calls.
This is all what is needed for Dom0 to work with OP-TEE as long
as Dom0 shares 1:1 mapped pages with OP-TEE. Any attempt to call
OP-TEE from DomU will fail and can lead to spectacular results.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/tee/Kconfig| 4 ++
xen/arch/arm/tee/Makefile | 1 +
xen/arch/arm/tee/optee.c| 134
xen/include/asm-arm/tee/optee_smc.h | 50 ++
4 files changed, 189 insertions(+)
create mode 100644 xen/arch/arm/tee/optee.c
diff --git a/xen/arch/arm/tee/Kconfig b/xen/arch/arm/tee/Kconfig
index e69de29..5b829db 100644
--- a/xen/arch/arm/tee/Kconfig
+++ b/xen/arch/arm/tee/Kconfig
@@ -0,0 +1,4 @@
+config OPTEE
+ bool "Enable OP-TEE mediator"
+ default n
+ depends on TEE
diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
index c54d479..982c879 100644
--- a/xen/arch/arm/tee/Makefile
+++ b/xen/arch/arm/tee/Makefile
@@ -1 +1,2 @@
obj-y += tee.o
+obj-$(CONFIG_OPTEE) += optee.o
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
new file mode 100644
index 000..7bb84d9
--- /dev/null
+++ b/xen/arch/arm/tee/optee.c
@@ -0,0 +1,134 @@
+/*
+ * xen/arch/arm/tee/optee.c
+ *
+ * OP-TEE mediator
+ *
+ * Volodymyr Babchuk
+ * Copyright (c) 2018 EPAM Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static bool optee_probe(void)
+{
+struct dt_device_node *node;
+struct arm_smccc_res resp;
+
+/* Check for entry in dtb */
+node = dt_find_compatible_node(NULL, NULL, "linaro,optee-tz");
+if ( !node )
+return false;
+
+/* Check UID */
+arm_smccc_smc(ARM_SMCCC_CALL_UID_FID(TRUSTED_OS_END), );
+
+if ( resp.a0 != OPTEE_MSG_UID_0 ||
+ resp.a1 != OPTEE_MSG_UID_1 ||
+ resp.a2 != OPTEE_MSG_UID_2 ||
+ resp.a3 != OPTEE_MSG_UID_3 )
+return false;
+
+return true;
+}
+
+static int optee_enable(struct domain *d)
+{
+struct arm_smccc_res resp;
+
+arm_smccc_smc(OPTEE_SMC_VM_CREATED, d->domain_id + 1, 0, 0, 0, 0, 0, 0,
+ );
+if ( resp.a0 != OPTEE_SMC_RETURN_OK ) {
+gprintk(XENLOG_WARNING, "OP-TEE don't want to support domain: %d\n",
+(uint32_t)resp.a0);
+return -ENODEV;
+}
+
+return 0;
+}
+
+static void forward_call(struct cpu_user_regs *regs)
+{
+struct arm_smccc_res resp;
+
+arm_smccc_smc(get_user_reg(regs, 0),
+ get_user_reg(regs, 1),
+ get_user_reg(regs, 2),
+ get_user_reg(regs, 3),
+ get_user_reg(regs, 4),
+ get_user_reg(regs, 5),
+ get_user_reg(regs, 6),
+ /* client id 0 is reserved for hypervisor itself */
+ current->domain->domain_id + 1,
+ );
+
+set_user_reg(regs, 0, resp.a0);
+set_user_reg(regs, 1, resp.a1);
+set_user_reg(regs, 2, resp.a2);
+set_user_reg(regs, 3, resp.a3);
+set_user_reg(regs, 4, 0);
+set_user_reg(regs, 5, 0);
+set_user_reg(regs, 6, 0);
+set_user_reg(regs, 7, 0);
+}
+
+static void optee_domain_destroy(struct domain *d)
+{
+struct arm_smccc_res resp;
+
+/* At this time all domain VCPUs should be stopped */
+
+/* Inform OP-TEE that domain is shutting down */
+arm_smccc_smc(OPTEE_SMC_VM_DESTROYED, d->domain_id + 1, 0, 0, 0, 0, 0, 0,
+ );
+}
+
+static bool optee_handle_call(struct cpu_user_regs *regs)
+{
+switch ( get_user_reg(regs, 0) )
+{
+case OPTEE_SMC_CALLS_COUNT:
+case OPTEE_SMC_CALLS_UID:
+case OPTEE_SMC_CALLS_REVISION:
+case OPTEE_SMC_CALL_GET_OS_UUID:
+case OPTEE_SMC_FUNCID_GET_OS_REVISION:
+case OPTEE_SMC_ENABLE_SHM_CACHE:
+case OPTEE_SMC_DISABLE_SHM_CACHE:
+case OPTEE_SMC_GET_SHM_CONFIG:
+case OPTEE_SMC_EXCHANGE_CAPABILITIES:
+case OPTEE_SMC_CALL_WITH_ARG:
+case OPTEE_SMC_CALL_RETURN_FROM_RPC:
+forward_call(regs);
+return true;
+default:
+return false;
+}
+}
+
+static const struct tee_mediator_ops optee_ops =
+{
+.probe = optee_probe,
+.enable = optee_enable,
+.domain_destroy = optee_domain_destroy,
+.handle_call = optee_handle_call,
+};
+
+REGISTER_TEE_MEDIATOR(optee, "OP-TEE", _ops);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/tee/optee_smc.h
b/xen/include/asm-arm/tee/optee_smc.h
index 26d100e..1c5a247 100644
--- a/xen/include/asm-arm/tee/optee_smc.h
+++ b/xen/include/asm-arm/tee/optee_smc.h
@@ -305,6 +305,56
[Xen-devel] [PATCH v2 00/13] TEE mediator (and OP-TEE) support in XEN
From: Volodymyr Babchuk Hello all, This is v2 of patch series for OP-TEE mediator support in XEN. Changes from v1: - Added domctl interface, so now xl decides what domain should work with TEE - Removed XSM support due to change described above - Patch with OP-TEE mediator was splited to 7 separate patches - Removed patch with call_smccc() function. Now this series depend on Julien Grall's series "xen/arm: SMCCC fixup and improvement" [3] = v1: This is follow for patch series [1]. There was lots of discussions for that series and I tried to address all of them in this new patchset. Currently, I had a working solution for OP-TEE virtualization and it is being upstreamed right now ([2]). So, I think it is a good time to introduce support in XEN as well. This series include generic TEE mediator framework and full-scale OP-TEE mediator which is working with mentioned chages in OP-TEE. So, multiple domains can work simultaneously with OP-TEE. I added XSM support, so now it is possible to control which domains can work with TEEs. Also I changed way how TEE discovery is done. Now it is very generic and should support any platform. [1] https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg01451.html [2] https://github.com/OP-TEE/optee_os/pull/2370 [3] https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02138.html Volodymyr Babchuk (13): arm: add generic TEE mediator framework domctl: add tee_op domctl arm: tee: add OP-TEE header files optee: add OP-TEE mediator skeleton optee: add fast calls handling optee: add domain contexts optee: add std call handling optee: add support for RPC SHM buffers optee: add support for arbitrary shared memory optee: add support for RPC commands libxc: add xc_dom_tee_enable(...) function xl: add "tee" option for xl.cfg lixl: arm: create optee firmware node in DT if tee=1 MAINTAINERS |6 + docs/man/xl.cfg.pod.5.in| 10 + tools/libxc/include/xenctrl.h |7 + tools/libxc/xc_domain.c | 13 + tools/libxl/libxl_arm.c | 59 +- tools/libxl/libxl_create.c |1 + tools/libxl/libxl_types.idl |1 + tools/xl/xl_parse.c |1 + xen/arch/arm/Kconfig|9 + xen/arch/arm/Makefile |1 + xen/arch/arm/domain.c |4 + xen/arch/arm/domain_build.c |4 + xen/arch/arm/domctl.c | 10 + xen/arch/arm/setup.c|1 + xen/arch/arm/shutdown.c |1 + xen/arch/arm/tee/Kconfig|4 + xen/arch/arm/tee/Makefile |2 + xen/arch/arm/tee/optee.c| 1042 +++ xen/arch/arm/tee/tee.c | 69 +++ xen/arch/arm/vsmc.c |5 + xen/arch/arm/xen.lds.S |7 + xen/include/asm-arm/tee/optee_msg.h | 444 +++ xen/include/asm-arm/tee/optee_smc.h | 507 + xen/include/asm-arm/tee/tee.h | 91 +++ xen/include/public/domctl.h |8 + 25 files changed, 2294 insertions(+), 13 deletions(-) create mode 100644 xen/arch/arm/tee/Kconfig create mode 100644 xen/arch/arm/tee/Makefile create mode 100644 xen/arch/arm/tee/optee.c create mode 100644 xen/arch/arm/tee/tee.c create mode 100644 xen/include/asm-arm/tee/optee_msg.h create mode 100644 xen/include/asm-arm/tee/optee_smc.h create mode 100644 xen/include/asm-arm/tee/tee.h -- 2.7.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 01/13] arm: add generic TEE mediator framework
This patch adds basic framework for TEE mediators. Guests can't talk
to TEE directly, we need some entity that will intercept request
and decide what to do with them. "TEE mediator" is a such entity.
This is how it works: user can build XEN with multiple TEE mediators
(see the next patches, where OP-TEE mediator is introduced).
TEE mediator register self with REGISTER_TEE_MEDIATOR() macro in the
same way, as device drivers use DT_DEVICE_START()/DT_DEVICE_END()
macros.
In runtime, during initialization, framework calls probe() function
for each available mediator driver to find which TEE is installed
on the platform. Then generic vSMC handler will call selected mediator
when it intercept SMC/HVC that belongs to TEE OS or TEE application.
Curently TEE mediator is enabled only for Dom0.
Signed-off-by: Volodymyr Babchuk
---
Changes from v1:
- Removed tee_remove() function
- CONFIG_TEE depends on EXPERT
- tee_domain_created() converted to tee_enable()
- tee_init() is called using initcall() mechanism
- tee_handle_smc() renamed to tee_handle_call()
Changes from "RFC" version:
- renamed CONFIG_ARM_TEE to CONFIG_TEE
- changed discovery mechanism: instead of UUID mathing, TEE-specific
probing is used
MAINTAINERS | 6 +++
xen/arch/arm/Kconfig | 9 +
xen/arch/arm/Makefile | 1 +
xen/arch/arm/domain.c | 4 ++
xen/arch/arm/domain_build.c | 4 ++
xen/arch/arm/setup.c | 1 +
xen/arch/arm/shutdown.c | 1 +
xen/arch/arm/tee/Kconfig | 0
xen/arch/arm/tee/Makefile | 1 +
xen/arch/arm/tee/tee.c| 69
xen/arch/arm/vsmc.c | 5 +++
xen/arch/arm/xen.lds.S| 7
xen/include/asm-arm/tee/tee.h | 91 +++
13 files changed, 199 insertions(+)
create mode 100644 xen/arch/arm/tee/Kconfig
create mode 100644 xen/arch/arm/tee/Makefile
create mode 100644 xen/arch/arm/tee/tee.c
create mode 100644 xen/include/asm-arm/tee/tee.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 1970100..605e6bd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -376,6 +376,12 @@ F: config/Stubdom.mk.in
F: m4/stubdom.m4
F: stubdom/
+TEE MEDIATORS
+M: Volodymyr Babchuk
+S: Supported
+F: xen/arch/arm/tee/
+F: xen/include/asm-arm/tee
+
TOOLSTACK
M: Ian Jackson
M: Wei Liu
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 586bc62..0968378 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -102,6 +102,13 @@ config HARDEN_BRANCH_PREDICTOR
If unsure, say Y.
+config TEE
+ bool "Enable TEE mediators support" if EXPERT = "y"
+ default n
+ help
+ This option enables generic TEE mediators support. It allows guests
+ to access real TEE via one of TEE mediators implemented in XEN.
+
endmenu
menu "ARM errata workaround via the alternative framework"
@@ -227,3 +234,5 @@ source "arch/arm/platforms/Kconfig"
source "common/Kconfig"
source "drivers/Kconfig"
+
+source "arch/arm/tee/Kconfig"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 37fa826..630d816 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -3,6 +3,7 @@ subdir-$(CONFIG_ARM_64) += arm64
subdir-y += platforms
subdir-$(CONFIG_ARM_64) += efi
subdir-$(CONFIG_ACPI) += acpi
+subdir-$(CONFIG_TEE) += tee
obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
obj-y += bootfdt.init.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 4baecc2..db5f5ef 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -902,6 +903,9 @@ int domain_relinquish_resources(struct domain *d)
*/
domain_vpl011_deinit(d);
+/* Free TEE mediator resources */
+tee_domain_destroy(d);
+
d->arch.relmem = RELMEM_xen;
/* Fallthrough */
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e1c79b2..d208ec7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2193,6 +2194,9 @@ int __init construct_dom0(struct domain *d)
set_current(saved_current);
p2m_restore_state(saved_current);
+/* Enable TEE */
+tee_enable(d);
+
discard_initial_modules();
memset(regs, 0, sizeof(*regs));
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 45f3841..680356f 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/xen/arch/arm/shutdown.c b/xen/arch/arm/shutdown.c
index b32f07e..30c6950 100644
--- a/xen/arch/arm/shutdown.c
+++ b/xen/arch/arm/shutdown.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
static void noreturn halt_this_cpu(void *arg)
{
diff --git
[Xen-devel] [PATCH v2 03/13] arm: tee: add OP-TEE header files
This header files describe protocol between OP-TEE and OP-TEE client
driver in Linux. They are needed for upcomient OP-TEE mediator, which
is added in the next patch.
Reason to add those headers in separate patch is to ease up review.
Those files were taken from linux tree (drivers/tee/optee/) and mangled
a bit to compile with XEN.
Signed-off-by: Volodymyr Babchuk
---
xen/include/asm-arm/tee/optee_msg.h | 444 +++
xen/include/asm-arm/tee/optee_smc.h | 457
2 files changed, 901 insertions(+)
create mode 100644 xen/include/asm-arm/tee/optee_msg.h
create mode 100644 xen/include/asm-arm/tee/optee_smc.h
diff --git a/xen/include/asm-arm/tee/optee_msg.h
b/xen/include/asm-arm/tee/optee_msg.h
new file mode 100644
index 000..10747b2
--- /dev/null
+++ b/xen/include/asm-arm/tee/optee_msg.h
@@ -0,0 +1,444 @@
+/*
+ * Copyright (c) 2015-2016, Linaro Limited
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ * this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifndef _OPTEE_MSG_H
+#define _OPTEE_MSG_H
+
+#include
+#include
+
+/*
+ * This file defines the OP-TEE message protocol used to communicate
+ * with an instance of OP-TEE running in secure world.
+ *
+ * This file is divided into three sections.
+ * 1. Formatting of messages.
+ * 2. Requests from normal world
+ * 3. Requests from secure world, Remote Procedure Call (RPC), handled by
+ *tee-supplicant.
+ */
+
+/*
+ * Part 1 - formatting of messages
+ */
+
+#define OPTEE_MSG_ATTR_TYPE_NONE 0x0
+#define OPTEE_MSG_ATTR_TYPE_VALUE_INPUT0x1
+#define OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT 0x2
+#define OPTEE_MSG_ATTR_TYPE_VALUE_INOUT0x3
+#define OPTEE_MSG_ATTR_TYPE_RMEM_INPUT 0x5
+#define OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT0x6
+#define OPTEE_MSG_ATTR_TYPE_RMEM_INOUT 0x7
+#define OPTEE_MSG_ATTR_TYPE_TMEM_INPUT 0x9
+#define OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT0xa
+#define OPTEE_MSG_ATTR_TYPE_TMEM_INOUT 0xb
+
+#define OPTEE_MSG_ATTR_TYPE_MASK GENMASK(7, 0)
+
+/*
+ * Meta parameter to be absorbed by the Secure OS and not passed
+ * to the Trusted Application.
+ *
+ * Currently only used with OPTEE_MSG_CMD_OPEN_SESSION.
+ */
+#define OPTEE_MSG_ATTR_METABIT(8)
+
+/*
+ * Pointer to a list of pages used to register user-defined SHM buffer.
+ * Used with OPTEE_MSG_ATTR_TYPE_TMEM_*.
+ * buf_ptr should point to the beginning of the buffer. Buffer will contain
+ * list of page addresses. OP-TEE core can reconstruct contiguous buffer from
+ * that page addresses list. Page addresses are stored as 64 bit values.
+ * Last entry on a page should point to the next page of buffer.
+ * Every entry in buffer should point to a 4k page beginning (12 least
+ * significant bits must be equal to zero).
+ *
+ * 12 least significant bints of optee_msg_param.u.tmem.buf_ptr should hold
page
+ * offset of the user buffer.
+ *
+ * So, entries should be placed like members of this structure:
+ *
+ * struct page_data {
+ * uint64_t pages_array[OPTEE_MSG_NONCONTIG_PAGE_SIZE/sizeof(uint64_t) - 1];
+ * uint64_t next_page_data;
+ * };
+ *
+ * Structure is designed to exactly fit into the page size
+ * OPTEE_MSG_NONCONTIG_PAGE_SIZE which is a standard 4KB page.
+ *
+ * The size of 4KB is chosen because this is the smallest page size for ARM
+ * architectures. If REE uses larger pages, it should divide them to 4KB ones.
+ */
+#define OPTEE_MSG_ATTR_NONCONTIG BIT(9)
+
+/*
+ * Memory attributes for
[Xen-devel] [PATCH v2 02/13] domctl: add tee_op domctl
Currently this call used only to enable TEE support for a domain.
It is planed to extend it when there will be multiple TEE
mediators, so toolstack can determine which TEE is available
on a platform.
Signed-off-by: Volodymyr Babchuk
---
xen/arch/arm/domctl.c | 10 ++
xen/include/public/domctl.h | 8
2 files changed, 18 insertions(+)
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 4587c75..f128d34 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
void arch_get_domain_info(const struct domain *d,
@@ -171,6 +172,15 @@ long arch_do_domctl(struct xen_domctl *domctl, struct
domain *d,
return rc;
}
+case XEN_DOMCTL_tee_op:
+switch ( domctl->u.tee_op.cmd )
+{
+case XEN_DOMCTL_TEE_OP_ENABLE:
+return tee_enable(d);
+
+default:
+return -EINVAL;
+}
default:
{
int rc;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 7fc07cc..d9820e0 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1093,6 +1093,12 @@ struct xen_domctl_vuart_op {
*/
};
+/* XEN_DOMCTL_tee_op */
+struct xen_domctl_tee_op {
+#define XEN_DOMCTL_TEE_OP_ENABLE 0
+uint32_t cmd; /* XEN_DOMCTL_TEE_OP_ */
+};
+
struct xen_domctl {
uint32_t cmd;
#define XEN_DOMCTL_createdomain 1
@@ -1172,6 +1178,7 @@ struct xen_domctl {
#define XEN_DOMCTL_soft_reset79
#define XEN_DOMCTL_set_gnttab_limits 80
#define XEN_DOMCTL_vuart_op 81
+#define XEN_DOMCTL_tee_op82
#define XEN_DOMCTL_gdbsx_guestmemio1000
#define XEN_DOMCTL_gdbsx_pausevcpu 1001
#define XEN_DOMCTL_gdbsx_unpausevcpu 1002
@@ -1233,6 +1240,7 @@ struct xen_domctl {
struct xen_domctl_psr_alloc psr_alloc;
struct xen_domctl_set_gnttab_limits set_gnttab_limits;
struct xen_domctl_vuart_op vuart_op;
+struct xen_domctl_tee_optee_op;
uint8_t pad[128];
} u;
};
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/5] xen/domain: Break __domain_destroy() out of domain_create() and complete_domain_destroy()
On Mon, Sep 03, 2018 at 03:46:57PM +0100, Andrew Cooper wrote:
> This is the first step in making the destroy path idepotent, and using it in
"idempotent".
> place of the ad-hoc cleanup paths in the create path.
>
> To begin with, the trivial free operations are broken out. The rest of the
> cleanup code will be moved as it is demonstrated (or made) to be idempotent.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger Pau Monné
> CC: Stefano Stabellini
> CC: Julien Grall
> ---
> xen/common/domain.c | 29 ++---
> 1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 43ab926..2253c2d 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -260,6 +260,23 @@ static int __init parse_extra_guest_irqs(const char *s)
> }
> custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>
> +/*
> + * Destroy a domain once all references to it have been dropped. Used either
> + * from the RCU path, or from the domain_create() error path before the
> domain
> + * is inserted into the domlist.
> + */
> +static void __domain_destroy(struct domain *d)
> +{
> +BUG_ON(!d->is_dying);
> +BUG_ON(atomic_read(>refcnt) != DOMAIN_DESTROYED);
> +
> +xfree(d->pbuf);
With this changed to XFREE here:
Reviewed-by: Wei Liu
> +
> +free_cpumask_var(d->dirty_cpumask);
On making things idempotent: this function seems to be a candidate.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen Dom0 boot failure on platform that supports ARM GICv4
Hi Julien,
Thanks for taking a look at this.
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 03 September 2018 17:13
> To: Shameerali Kolothum Thodi ;
> xen-de...@lists.xen.org
> Cc: sstabell...@kernel.org; Linuxarm ; Andre
> Przywara
> Subject: Re: Xen Dom0 boot failure on platform that supports ARM GICv4
>
>
>
> On 03/09/18 15:53, Shameerali Kolothum Thodi wrote:
> > Hi,
>
> Hello,
>
> > I am trying to boot xen(stable-4.11) on one of our ARM64 boards which
> > has support for GICv4.
> >
> > But dom0(kernel 4.18) boot fails with the below trap,
> >
> > XEN) done.
> > (XEN) Std. Loglevel: All
> > (XEN) Guest Loglevel: All
> > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> > input to Xen)
> > (XEN) Freed 304kB init memory.
> > (XEN) traps.c:2007:d0v0 HSR=0x9384 pc=0x0841af04
> > gva=0x0b10ffe8 gpa=0x004000aa10ffe8
>
> Which bits of Linux is trying to access the region?
I think it is the gic_iterate_rdists() as the offset just before this is ffe8,
which is GICR_PIDR2
> >
> > After a bit of debugging, it looks like, the GICR size used in
> vgic_v3_domain_init()
> > is GICv4 GICR size(256K) and this upsets the first_cpu calculations.
>
> Can you expand what you mean by upset? What's wrong with the first_cpu
> calculations.
What I meant is, since this is a GICv4, the vgic_v3_hw.regions[i]->size is set
to 256K and
since first_cpu is calculated like,
first_cpu += size /GICV3_GICR_SIZE;
gets wrong as what I am seeing is,
(XEN) frst_cpu 2
(XEN) first_cpu 4
(XEN) first_cpu 6
(XEN) first_cpu 8
(XEN) first_cpu 10
(XEN) first_cpu 12
(XEN) first_cpu 14
.
(XEN) first_cpu 192
But the original number of CPUS are only 96. Hence I thought this is wrong.
> >
> > Since dom0 gicv3 is also an emulated one, I think the size should be
> > restricted to use the GICv3 GICR size(128K). I have made the below
> > changes and is able to boot dom0 now.
> >
> > But not sure, this is the right approach to fix the issue. Please let me
> > know your thoughts.
> >
> > Thanks,
> > Shameer
> >
> > >8-
> >
> > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> > index b2ed0f8..bf028cc 100644
> > --- a/xen/arch/arm/gic-v3.c
> > +++ b/xen/arch/arm/gic-v3.c
> > @@ -1783,7 +1783,8 @@ static int __init gicv3_init(void)
> > reg = readl_relaxed(GICD + GICD_TYPER);
> > intid_bits = GICD_TYPE_ID_BITS(reg);
> >
> > -vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
> intid_bits);
> > +vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
> > +intid_bits, gic_dist_supports_dvis());
> > gicv3_init_v2();
> >
> > spin_lock_init();
> > diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> > index 4b42739..0f53d88 100644
> > --- a/xen/arch/arm/vgic-v3.c
> > +++ b/xen/arch/arm/vgic-v3.c
> > @@ -59,18 +59,21 @@ static struct {
> > unsigned int nr_rdist_regions;
> > const struct rdist_region *regions;
> > unsigned int intid_bits; /* Number of interrupt ID bits */
> > +bool dvis;
> > } vgic_v3_hw;
> >
> > void vgic_v3_setup_hw(paddr_t dbase,
> > unsigned int nr_rdist_regions,
> > const struct rdist_region *regions,
> > - unsigned int intid_bits)
> > + unsigned int intid_bits,
> > + bool dvis)
> > {
> > vgic_v3_hw.enabled = true;
> > vgic_v3_hw.dbase = dbase;
> > vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
> > vgic_v3_hw.regions = regions;
> > vgic_v3_hw.intid_bits = intid_bits;
> > +vgic_v3_hw.dvis = dvis;
> > }
> >
> > static struct vcpu *vgic_v3_irouter_to_vcpu(struct domain *d, uint64_t
> irouter)
> > @@ -1673,6 +1676,9 @@ static int vgic_v3_domain_init(struct domain *d)
> > {
> > paddr_t size = vgic_v3_hw.regions[i].size;
> >
> > +if (vgic_v3_hw.dvis && (size == GICV4_GICR_SIZE))
> > + size = GICV3_GICR_SIZE;
>
> vgic_v3_hw.regions is describing the regions in the layout that could
> hold re-distributor. You can have multiple re-distributor per region.
>
> The variable size holds the size of the region, not the size of the
> re-distributor.
>
> I am not sure to understand why you want to restrict the size of the
> region here because GICV4_GICR_SIZE is a multiple of GICV3_GICR_SIZE. So
> you should be able to fit 2 re-distributors per region.
>
> It looks like to me the re-distributor regions are not reported
> correctly or Dom0 thinks it is on GICv4. Can you provide a bit more
> details on the function that cause the crash and some logs from Linux?
Ok. I added few prints along the vgic mmio read path and this is what happens
before the trap.
vgic_v3_rdistr_mmio_read()
get_vcpu_from_rdist() -->returns NULL here for 0x004000aa10ffe8 which
[Xen-devel] [PATCH] xen/x86: Ignore the automatically generated include/asm-x86/asm-macros.h
Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index a7cc3f3..ab53fc4 100644 --- a/.gitignore +++ b/.gitignore @@ -311,6 +311,7 @@ xen/arch/*/efi/runtime.c xen/include/headers*.chk xen/include/asm xen/include/asm-*/asm-offsets.h +xen/include/asm-x86/asm-macros.h xen/include/compat/* xen/include/config/ xen/include/generated/ -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/5] xen/domain: Prepare data for is_{pv, hvm}_domain() as early as possible
On Mon, Sep 03, 2018 at 03:46:56PM +0100, Andrew Cooper wrote: > Given two subtle failures from getting this wrong before, and more cleanup on > the way, move the setting of d->guest_type as early as possible. > > Note that despite moving the assignment of d->guest_type outside of the > is_idle_domain(d) check, it still behaves the same. Previously, system > domains had no direct assignment of d->guest_type and behaved as PV guests > because guest_type_pv has the value 0. > > While tidying up the predicate, leave a comment refering to > is_system_domain(), and move the associated ASSERT() to be beside the > asignment. > > 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 v4] x86/hvm: remove default ioreq server (again)
My recent patch [1] to qemu-xen-traditional removes the last use of the
'default' ioreq server in Xen. (This is a catch-all ioreq server that is
used if no explicitly registered I/O range is targetted).
This patch can be applied once that patch is committed, to remove the
(>100 lines of) redundant code in Xen.
The previous version of this patch caused a QEMU build failure. This has
been fixed by extending the #ifdef around deprecated HVM_PARAM declarations
to __XEN_TOOLS__ as well as __XEN__.
NOTE: The removal of the special case for HVM_PARAM_DM_DOMAIN in
hvm_allow_set_param() is not directly related to removal of
default ioreq servers. It could have been cleaned up at any time
after commit 9a422c03 "x86/hvm: stop passing explicit domid to
hvm_create_ioreq_server()". It is now added to the new
deprecated sets introduced by this patch.
[1] https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg00270.html
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: Jan Beulich
v4:
- Re-base.
- Pull deprecated params up to the top of the header.
- Fix build failure and extend commit comment noting this.
- Drop Andrew's A-b due to re-work.
v3:
- Add HVM_PARAM_DM_DOMAIN to deprecated sets and #ifdef in params.h.
v2:
- Disallow reads or writes of HVM_PARAM_BUFIOREQ_EVTCHN and mark it as
deprecated in the header.
- Updated commit comment w.r.t. HVM_PARAM_DM_DOMAIN change.
---
xen/arch/x86/hvm/dm.c| 2 +-
xen/arch/x86/hvm/hvm.c | 38 +++-
xen/arch/x86/hvm/ioreq.c | 122 +--
xen/include/asm-x86/hvm/domain.h | 1 -
xen/include/asm-x86/hvm/ioreq.h | 4 +-
xen/include/public/hvm/params.h | 12 ++--
6 files changed, 36 insertions(+), 143 deletions(-)
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 87d97d055f..ba39e4f4f9 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -411,7 +411,7 @@ static int dm_op(const struct dmop_args *op_args)
if ( data->pad[0] || data->pad[1] || data->pad[2] )
break;
-rc = hvm_create_ioreq_server(d, false, data->handle_bufioreq,
+rc = hvm_create_ioreq_server(d, data->handle_bufioreq,
>id);
break;
}
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ac067a8d38..64373ced20 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4084,12 +4084,16 @@ static int hvm_allow_set_param(struct domain *d,
case HVM_PARAM_CONSOLE_EVTCHN:
case HVM_PARAM_X87_FIP_WIDTH:
break;
+/* The following parameters are deprecated. */
+case HVM_PARAM_DM_DOMAIN:
+case HVM_PARAM_BUFIOREQ_EVTCHN:
+rc = -EPERM;
+break;
/*
* The following parameters must not be set by the guest
* since the domain may need to be paused.
*/
case HVM_PARAM_IDENT_PT:
-case HVM_PARAM_DM_DOMAIN:
case HVM_PARAM_ACPI_S_STATE:
/* The remaining parameters should not be set by the guest. */
default:
@@ -4254,9 +4258,6 @@ static int hvmop_set_param(
d->arch.hvm.params[HVM_PARAM_NESTEDHVM] )
rc = -EINVAL;
break;
-case HVM_PARAM_BUFIOREQ_EVTCHN:
-rc = -EINVAL;
-break;
case HVM_PARAM_TRIPLE_FAULT_REASON:
if ( a.value > SHUTDOWN_MAX )
rc = -EINVAL;
@@ -4364,13 +4365,11 @@ static int hvm_allow_get_param(struct domain *d,
case HVM_PARAM_ALTP2M:
case HVM_PARAM_X87_FIP_WIDTH:
break;
-/*
- * The following parameters must not be read by the guest
- * since the domain may need to be paused.
- */
-case HVM_PARAM_IOREQ_PFN:
-case HVM_PARAM_BUFIOREQ_PFN:
+/* The following parameters are deprecated. */
+case HVM_PARAM_DM_DOMAIN:
case HVM_PARAM_BUFIOREQ_EVTCHN:
+rc = -ENODATA;
+break;
/* The remaining parameters should not be read by the guest. */
default:
if ( d == current->domain )
@@ -4424,25 +4423,6 @@ static int hvmop_get_param(
case HVM_PARAM_X87_FIP_WIDTH:
a.value = d->arch.x87_fip_width;
break;
-case HVM_PARAM_IOREQ_PFN:
-case HVM_PARAM_BUFIOREQ_PFN:
-case HVM_PARAM_BUFIOREQ_EVTCHN:
-/*
- * It may be necessary to create a default ioreq server here,
- * because legacy versions of QEMU are not aware of the new API for
- * explicit ioreq server creation. However, if the domain is not
- * under construction then it will not be QEMU querying the
- * parameters and thus the query should not have that side-effect.
- */
-if ( !d->creation_finished )
-{
-rc = hvm_create_ioreq_server(d, true,
- HVM_IOREQSRV_BUFIOREQ_LEGACY, NULL);
-if ( rc != 0 && rc != -EEXIST )
-goto out;
-}
-
-/*FALLTHRU*/
default:
Re: [Xen-devel] [PATCH v2 2/6] x86emul: extend MASKMOV{Q, DQU} tests
On 29/08/18 15:23, Jan Beulich wrote: > While deriving the first AVX512 pieces from existing code I've got the > (in the end wrong) impression that the emulation of these insns would be > broken. Besides testing that the instructions act as no-ops when the > controlling mask bits are all zero, add ones to also check that the data > merging actually works. > > 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 v2 1/6] x86emul: fix FMA scalar operand sizes
On 29/08/18 15:23, Jan Beulich wrote: > FMA insns, other than the earlier AVX additions, don't use the low > opcode bit to distinguish between single and double vector elements. I think I've worked out why "other than the" is so weird to read as a native speaker here. I think you mean "unlike the" in this context. > While the difference is benign for packed flavors, the scalar ones > need to use VEX.W here. Oddly enough the table entries didn't even use > simd_scalar_fp, but uniformly used simd_packed_fp (implying the > distinction was by [VEX-encoded] opcode prefix). Was this a bug in the FMA patch then? > > Split simd_scalar_fp into simd_scalar_opc and simd_scalar_vexw, and > correct Missing the rest of the sentence? (v1 was similar) > > Also correct the scalar insn comments (they only ever use XMM registers > as operands). > > Signed-off-by: Jan Beulich As for the code content, Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] x86/HVM: also stuff RSB upon exit to guest
On 27/07/18 15:20, Jan Beulich wrote:
> In order to mostly eliminate abuse of what Xen leaves in the RSB by
> guest level attackers, fill the RSB with almost-NULL pointers right
> before entering guest context.
How do you envisage an attacker using what Xen leaves in the RSB? An
attacker doesn't have much/any control of the callgraph Xen makes.
>
> The placement of the initialization code is intentional: If it was put
> in e.g. hvm_enable(), we'd have to be more careful wrt. changing the
> low L4 entry of the idle page tables (I didn't check whether boot time
> low mappings have disappeared by then), and get_random() couldn't be
> used either. Furthermore this way, if no HVM guest gets ever started,
> no setup would ever occur.
>
> Signed-off-by: Jan Beulich
> ---
> TBD: In the end I'm not sure the (pseudo-)randomness is worth it.
> Placing the stub uniformly at a fixed address would allow to get
> rid of the variable, slightly streamlining the call sites.
> TBD: Obviously using NULL here has the downside of reads through NULL
> not going to fault anymore.
This alone is sufficient justification to not use this route. Ideally,
we should have no mappings within disp32 of 0.
In principle, there are other better addresses which could be used, such
as the page immediately below the canonical boundary, or TSEG/HSEG, but...
>
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -85,6 +85,10 @@ integer_param("hvm_debug", opt_hvm_debug
>
> struct hvm_function_table hvm_funcs __read_mostly;
>
> +extern void do_overwrite_rsb(void);
> +extern const char do_overwrite_rsb_end[];
> +void (* __read_mostly hvm_overwrite_rsb)(void) = do_overwrite_rsb;
> +
> /*
> * The I/O permission bitmap is globally shared by all HVM guests except
> * the hardware domain which needs a more permissive one.
> @@ -583,6 +587,49 @@ int hvm_domain_initialise(struct domain
> return -EINVAL;
> }
>
> +if ( boot_cpu_has(X86_FEATURE_SC_RSB_HVM) &&
> + unlikely((unsigned long)hvm_overwrite_rsb >= PAGE_SIZE) )
> +{
> +/*
> + * Map an RSB stuffing routine at a random, 16-byte aligned address
> + * in the first linear page, to allow filling the RSB with
> almost-NULL
> + * pointers before entering HVM guest context. This builds on the
> + * assumption that no sane OS will place anything there which could
> be
> + * abused as an exploit gadget.
> + */
> +unsigned long addr = (get_random() << 4) & ~PAGE_MASK;
> +unsigned int size = do_overwrite_rsb_end -
> +(const char *)do_overwrite_rsb;
> +struct page_info *pg = alloc_domheap_page(NULL, 0);
> +void *ptr;
> +
> +if ( !pg ||
> + map_pages_to_xen(0, page_to_mfn(pg), 1, PAGE_HYPERVISOR_RX) )
> +{
> +if ( pg )
> +free_domheap_page(pg);
> +return -ENOMEM;
> +}
> +
> +/*
> + * Avoid NULL itself, so that branches there will hit the all-ones
> + * pattern installed below.
> + */
> +if ( !addr )
> +addr = 0x10;
> +while ( addr + size > PAGE_SIZE )
> +addr -= 0x10;
addr = max(0x10, min(addr, PAGE_SIZE - ROUNDUP(size, 0x10)));
although I'd agree that the randomisation doesn't help much here.
> +
> +ptr = __map_domain_page(pg);
> +memset(ptr, -1, PAGE_SIZE);
> +memcpy(ptr + addr, do_overwrite_rsb, size);
> +unmap_domain_page(ptr);
> +
> +smp_wmb();
What is this barrier for?
> +hvm_overwrite_rsb = (void *)addr;
> +printk(XENLOG_INFO "RSB stuffing stub at %p\n", hvm_overwrite_rsb);
> +}
> +
> spin_lock_init(>arch.hvm_domain.irq_lock);
> spin_lock_init(>arch.hvm_domain.uc_lock);
> spin_lock_init(>arch.hvm_domain.write_map.lock);
> --- a/xen/include/asm-x86/spec_ctrl_asm.h
> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
> @@ -249,6 +249,8 @@
>
> /* Use when exiting to HVM guest context. */
> #define SPEC_CTRL_EXIT_TO_HVM \
> +mov hvm_overwrite_rsb(%rip), %rcx; \
> +ALTERNATIVE "", "INDIRECT_CALL %rcx", X86_FEATURE_SC_RSB_HVM; \
... there are two reasons why I didn't do any RSB stuffing along these
lines.
First, this is racy with NMIs/etc.
Secondly, SMM mode does exactly the same to the whole system (outside of
Xens control) with a call tree in HSEG/TSEG.
If we are running natively, we can work out HSEG/TSEG and in principle
make Xen's stuffing plausibly look like the SMM handler. If Xen is
running virtualised, then we can't.
Overall, given the holes in the available mechanism, and the fact that
Xen's current callgraph is actually pretty good (wrt RSB) for current
operating systems, I didn't think it was worth doing anything special.
~Andrew
___
Xen-devel mailing
Re: [Xen-devel] [PATCH v2 2/2] x86/HVM: split page straddling emulated accesses in more cases
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 03 September 2018 16:45
> To: xen-devel
> Cc: Olaf Hering ; Andrew Cooper
> ; Paul Durrant
> Subject: [PATCH v2 2/2] x86/HVM: split page straddling emulated accesses in
> more cases
>
> Assuming consecutive linear addresses map to all RAM or all MMIO is not
> correct. Nor is assuming that a page straddling MMIO access will access
> the same emulating component for both parts of the access. If a guest
> RAM read fails with HVMTRANS_bad_gfn_to_mfn and if the access straddles
> a page boundary, issue accesses separately for both parts.
>
> The extra call to known_glfn() from hvmemul_write() is just to preserve
> original behavior; we should consider dropping this (also to make sure
> the intended effect of 8cbd4fb0b7 ["x86/hvm: implement hvmemul_write()
> using real mappings"] is achieved in all cases where it can be achieved
> without further rework), or alternatively we perhaps ought to mirror
> this in hvmemul_rmw().
>
> Note that the correctness of this depends on the MMIO caching used
> elsewhere in the emulation code.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Also handle hvmemul_{write,rmw}().
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1041,6 +1041,110 @@ static inline int hvmemul_linear_mmio_wr
>pfec, hvmemul_ctxt, translate);
> }
>
> +static bool known_glfn(unsigned long addr, unsigned int bytes, uint32_t
> pfec)
> +{
> +const struct hvm_vcpu_io *vio = >arch.hvm.hvm_io;
> +
> +if ( pfec & PFEC_write_access )
> +{
> +if ( !vio->mmio_access.write_access )
> +return false;
> +}
> +else if ( pfec & PFEC_insn_fetch )
> +{
> +if ( !vio->mmio_access.insn_fetch )
> +return false;
> +}
> +else if ( !vio->mmio_access.read_access )
> +return false;
> +
> +return (vio->mmio_gla == (addr & PAGE_MASK) &&
> +(addr & ~PAGE_MASK) + bytes <= PAGE_SIZE);
> +}
> +
Would it be possible to split the introduction of the above function into a
separate patch? AFAICT it does not seem to be intrinsically involved with
handle page straddling. It was certainly not there in your RFC patch.
Paul
> +static int linear_read(unsigned long addr, unsigned int bytes, void *p_data,
> + uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt)
> +{
> +pagefault_info_t pfinfo;
> +int rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec,
> );
> +
> +switch ( rc )
> +{
> +unsigned int offset, part1;
> +
> +case HVMTRANS_okay:
> +return X86EMUL_OKAY;
> +
> +case HVMTRANS_bad_linear_to_gfn:
> +x86_emul_pagefault(pfinfo.ec, pfinfo.linear, _ctxt->ctxt);
> +return X86EMUL_EXCEPTION;
> +
> +case HVMTRANS_bad_gfn_to_mfn:
> +if ( pfec & PFEC_insn_fetch )
> +return X86EMUL_UNHANDLEABLE;
> +
> +offset = addr & ~PAGE_MASK;
> +if ( offset + bytes <= PAGE_SIZE )
> +return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec,
> +hvmemul_ctxt,
> +known_glfn(addr, bytes, pfec));
> +
> +/* Split the access at the page boundary. */
> +part1 = PAGE_SIZE - offset;
> +rc = linear_read(addr, part1, p_data, pfec, hvmemul_ctxt);
> +if ( rc == X86EMUL_OKAY )
> +rc = linear_read(addr + part1, bytes - part1, p_data + part1,
> + pfec, hvmemul_ctxt);
> +return rc;
> +
> +case HVMTRANS_gfn_paged_out:
> +case HVMTRANS_gfn_shared:
> +return X86EMUL_RETRY;
> +}
> +
> +return X86EMUL_UNHANDLEABLE;
> +}
> +
> +static int linear_write(unsigned long addr, unsigned int bytes, void *p_data,
> +uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt)
> +{
> +pagefault_info_t pfinfo;
> +int rc = hvm_copy_to_guest_linear(addr, p_data, bytes, pfec, );
> +
> +switch ( rc )
> +{
> +unsigned int offset, part1;
> +
> +case HVMTRANS_okay:
> +return X86EMUL_OKAY;
> +
> +case HVMTRANS_bad_linear_to_gfn:
> +x86_emul_pagefault(pfinfo.ec, pfinfo.linear, _ctxt->ctxt);
> +return X86EMUL_EXCEPTION;
> +
> +case HVMTRANS_bad_gfn_to_mfn:
> +offset = addr & ~PAGE_MASK;
> +if ( offset + bytes <= PAGE_SIZE )
> +return hvmemul_linear_mmio_write(addr, bytes, p_data, pfec,
> + hvmemul_ctxt,
> + known_glfn(addr, bytes, pfec));
> +
> +/* Split the access at the page boundary. */
> +part1 = PAGE_SIZE - offset;
> +rc = linear_write(addr, part1, p_data, pfec, hvmemul_ctxt);
> +if ( rc == X86EMUL_OKAY )
> +rc = linear_write(addr + part1, bytes - part1, p_data + part1,
> +
Re: [Xen-devel] Xen Dom0 boot failure on platform that supports ARM GICv4
On 03/09/18 15:53, Shameerali Kolothum Thodi wrote:
Hi,
Hello,
I am trying to boot xen(stable-4.11) on one of our ARM64 boards which
has support for GICv4.
But dom0(kernel 4.18) boot fails with the below trap,
XEN) done.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 304kB init memory.
(XEN) traps.c:2007:d0v0 HSR=0x9384 pc=0x0841af04
gva=0x0b10ffe8 gpa=0x004000aa10ffe8
Which bits of Linux is trying to access the region?
After a bit of debugging, it looks like, the GICR size used in
vgic_v3_domain_init()
is GICv4 GICR size(256K) and this upsets the first_cpu calculations.
Can you expand what you mean by upset? What's wrong with the first_cpu
calculations.
Since dom0 gicv3 is also an emulated one, I think the size should be
restricted to use the GICv3 GICR size(128K). I have made the below
changes and is able to boot dom0 now.
But not sure, this is the right approach to fix the issue. Please let me
know your thoughts.
Thanks,
Shameer
>8-
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b2ed0f8..bf028cc 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1783,7 +1783,8 @@ static int __init gicv3_init(void)
reg = readl_relaxed(GICD + GICD_TYPER);
intid_bits = GICD_TYPE_ID_BITS(reg);
-vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions, intid_bits);
+vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
+intid_bits, gic_dist_supports_dvis());
gicv3_init_v2();
spin_lock_init();
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4b42739..0f53d88 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -59,18 +59,21 @@ static struct {
unsigned int nr_rdist_regions;
const struct rdist_region *regions;
unsigned int intid_bits; /* Number of interrupt ID bits */
+bool dvis;
} vgic_v3_hw;
void vgic_v3_setup_hw(paddr_t dbase,
unsigned int nr_rdist_regions,
const struct rdist_region *regions,
- unsigned int intid_bits)
+ unsigned int intid_bits,
+ bool dvis)
{
vgic_v3_hw.enabled = true;
vgic_v3_hw.dbase = dbase;
vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
vgic_v3_hw.regions = regions;
vgic_v3_hw.intid_bits = intid_bits;
+vgic_v3_hw.dvis = dvis;
}
static struct vcpu *vgic_v3_irouter_to_vcpu(struct domain *d, uint64_t irouter)
@@ -1673,6 +1676,9 @@ static int vgic_v3_domain_init(struct domain *d)
{
paddr_t size = vgic_v3_hw.regions[i].size;
+if (vgic_v3_hw.dvis && (size == GICV4_GICR_SIZE))
+ size = GICV3_GICR_SIZE;
vgic_v3_hw.regions is describing the regions in the layout that could
hold re-distributor. You can have multiple re-distributor per region.
The variable size holds the size of the region, not the size of the
re-distributor.
I am not sure to understand why you want to restrict the size of the
region here because GICV4_GICR_SIZE is a multiple of GICV3_GICR_SIZE. So
you should be able to fit 2 re-distributors per region.
It looks like to me the re-distributor regions are not reported
correctly or Dom0 thinks it is on GICv4. Can you provide a bit more
details on the function that cause the crash and some logs from Linux?
Also, which Linux version are you using?
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 5/5] xen/domain: Make rangeset_domain_destroy() idempotent
>>> On 03.09.18 at 16:47, wrote: > ... and move it into the common __domain_destroy() path. > > 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 4/5] xen/domain: Fold xsm_free_security_domain() paths together
>>> On 03.09.18 at 16:46, wrote: > xsm_free_security_domain() is idempotent (both the dummy handler, and the > flask handler). Move it into the shared __domain_destroy() path, and drop the > INIT_xsm flag from domain_create() > > 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 3/5] xen/domain: Call lock_profile_deregister_struct() from common code
>>> On 03.09.18 at 16:46, wrote: > lock_profile_register_struct() is called from common code, but the matching > deregister was previously only called from x86 code. > > The practical upshot of this when using CONFIG_LOCK_PROFILE, destroyed domains > on ARM (and in particular, the freed page behind struct domain) remain on the > lockprofile linked list, which will become corrupt when the page is reused. > > Signed-off-by: Andrew Cooper 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 2/5] xen/domain: Break __domain_destroy() out of domain_create() and complete_domain_destroy()
>>> On 03.09.18 at 16:46, wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -260,6 +260,23 @@ static int __init parse_extra_guest_irqs(const char *s)
> }
> custom_param("extra_guest_irqs", parse_extra_guest_irqs);
>
> +/*
> + * Destroy a domain once all references to it have been dropped. Used either
> + * from the RCU path, or from the domain_create() error path before the
> domain
> + * is inserted into the domlist.
> + */
> +static void __domain_destroy(struct domain *d)
With just a single leading underscore
Acked-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/5] xen/domain: Prepare data for is_{pv, hvm}_domain() as early as possible
>>> On 03.09.18 at 16:46, wrote: > Given two subtle failures from getting this wrong before, and more cleanup on > the way, move the setting of d->guest_type as early as possible. > > Note that despite moving the assignment of d->guest_type outside of the > is_idle_domain(d) check, it still behaves the same. Previously, system > domains had no direct assignment of d->guest_type and behaved as PV guests > because guest_type_pv has the value 0. > > While tidying up the predicate, leave a comment refering to > is_system_domain(), and move the associated ASSERT() to be beside the > asignment. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -272,8 +272,12 @@ struct domain *domain_create(domid_t domid, > if ( (d = alloc_domain_struct()) == NULL ) > return ERR_PTR(-ENOMEM); > > +/* Sort out our idea of is_system_domain(). */ > d->domain_id = domid; > > +/* Debug sanity. */ > +ASSERT(is_system_domain(d) ? config == NULL : config != NULL); Would you mind shortening this to at least ASSERT(is_system_domain(d) ? !config : config); while you move it? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit
Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a
domain to change the value of the #VE suppress bit for a page.
Add a libxc wrapper for invoking this hvmop.
Signed-off-by: Adrian Pop
Acked-by: Wei Liu
Acked-by: Tamas K Lengyel
---
Changes in v5:
- remove the "set_" from struct xen_hvm_altp2m_set_suppress_ve
Changes in v4:
- fix a deadlock:
If p2m_set_suppress_ve() is called on invalid pages the code path
wrongly returns without releasing the lock, resulting in a deadlock.
- remove the privileged domain check
Changes in v3:
- fix indentation (Wei Liu)
- use return values other than EINVAL where appropriate (Ian Beulich)
- remove the irrelevant comments from the
xen_hvm_altp2m_set_suppress_ve struct (Ian Beulich)
- add comment for the suppress_ve field in the struct above (Ian
Beulich)
- remove the typedef and DEFINE_XEN_GUEST_HANDLE for
xen_hvm_altp2m_set_suppress_ve (Ian Beulich)
- use XSM_DM_PRIV check instead of domain->is_privileged (Ian Beulich)
Changes in v2:
- check if #VE has been enabled on the target domain (Tamas K Lengyel)
- check if the cpu has the #VE feature
- make the suppress_ve argument boolean (Jan Beulich)
- initialize only local variables that need initializing (Jan Beulich)
- use fewer local variables (Jan Beulich)
- fix indentation (Jan Beulich)
- remove unnecessary braces (Jan Beulich)
- use gfn_lock() instead of p2m_lock() in the non-altp2m case (Jan
Beulich)
- merge patch #2 and patch #3 (Jan Beulich)
---
tools/libxc/include/xenctrl.h | 2 ++
tools/libxc/xc_altp2m.c | 24 ++
xen/arch/x86/hvm/hvm.c | 14 +
xen/arch/x86/mm/mem_access.c| 55 +
xen/include/public/hvm/hvm_op.h | 11 +++
xen/include/xen/mem_access.h| 3 ++
6 files changed, 109 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c626984aba..cc8b3e7dce 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1952,6 +1952,8 @@ int xc_altp2m_destroy_view(xc_interface *handle, uint32_t
domid,
/* Switch all vCPUs of the domain to the specified altp2m view */
int xc_altp2m_switch_to_view(xc_interface *handle, uint32_t domid,
uint16_t view_id);
+int xc_altp2m_set_suppress_ve(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, xen_pfn_t gfn, bool sve);
int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
uint16_t view_id, xen_pfn_t gfn,
xenmem_access_t access);
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index ce4a1e4d60..f883d0b392 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -163,6 +163,30 @@ int xc_altp2m_switch_to_view(xc_interface *handle,
uint32_t domid,
return rc;
}
+int xc_altp2m_set_suppress_ve(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, xen_pfn_t gfn, bool sve)
+{
+int rc;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+
+arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+arg->cmd = HVMOP_altp2m_set_suppress_ve;
+arg->domain = domid;
+arg->u.suppress_ve.view = view_id;
+arg->u.suppress_ve.gfn = gfn;
+arg->u.suppress_ve.suppress_ve = sve;
+
+rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+ HYPERCALL_BUFFER_AS_ARG(arg));
+
+xc_hypercall_buffer_free(handle, arg);
+return rc;
+}
+
int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t domid,
uint16_t view_id, xen_pfn_t gfn,
xenmem_access_t access)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 72c51faecb..64ab36ff53 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4524,6 +4524,7 @@ static int do_altp2m_op(
case HVMOP_altp2m_create_p2m:
case HVMOP_altp2m_destroy_p2m:
case HVMOP_altp2m_switch_p2m:
+case HVMOP_altp2m_set_suppress_ve:
case HVMOP_altp2m_set_mem_access:
case HVMOP_altp2m_set_mem_access_multi:
case HVMOP_altp2m_change_gfn:
@@ -4641,6 +4642,19 @@ static int do_altp2m_op(
rc = p2m_switch_domain_altp2m_by_id(d, a.u.view.view);
break;
+case HVMOP_altp2m_set_suppress_ve:
+if ( a.u.suppress_ve.pad1 || a.u.suppress_ve.pad2 )
+rc = -EINVAL;
+else
+{
+gfn_t gfn = _gfn(a.u.set_mem_access.gfn);
+unsigned int altp2m_idx = a.u.set_mem_access.view;
+bool suppress_ve = a.u.suppress_ve.suppress_ve;
+
+rc = p2m_set_suppress_ve(d, gfn, suppress_ve, altp2m_idx);
+}
+break;
+
case HVMOP_altp2m_set_mem_access:
if ( a.u.set_mem_access.pad )
rc = -EINVAL;
diff --git
[Xen-devel] [PATCH v5 0/3] Add hvmops for setting and getting the suppress #VE bit
As the code stands right now, after DomU has enabled #VE using HVMOP_altp2m_vcpu_enable_notify, all its pages have the #VE suppress bit cleared, generating #VEs for any EPT violation. There is currently no way to change the value of the #VE suppress bit for a page from a domain; it can only be done in Xen internally using ept_set_entry(). Following the discussion from https://lists.xen.org/archives/html/xen-devel/2017-03/msg01312.html these patches introduce new hvmops for setting and getting this bit and thus Adrian Pop (3): x86/altp2m: Add a hvmop for setting the suppress #VE bit x86/altp2m: Add a hvmop for querying the suppress #VE bit Vlad Ioan Topan (1): x86/mm: Change default value for suppress #VE in set_mem_access() tools/libxc/include/xenctrl.h | 4 ++ tools/libxc/xc_altp2m.c | 50 xen/arch/x86/hvm/hvm.c | 33 ++ xen/arch/x86/mm/mem_access.c| 103 +++- xen/include/public/hvm/hvm_op.h | 13 xen/include/xen/mem_access.h| 6 ++ 6 files changed, 207 insertions(+), 2 deletions(-) -- 2.18.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v5 1/3] x86/mm: Change default value for suppress #VE in set_mem_access()
From: Vlad Ioan Topan The default value for the "suppress #VE" bit set by set_mem_access() currently depends on whether the call is made from the same domain (the bit is set when called from another domain and cleared if called from the same domain). This patch changes that behavior to inherit the old suppress #VE bit value if it is already set and to set it to 1 otherwise, which is safer and more reliable. Signed-off-by: Vlad Ioan Topan Signed-off-by: Adrian Pop --- xen/arch/x86/mm/mem_access.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c index 84d260ebd8..e1522a0b75 100644 --- a/xen/arch/x86/mm/mem_access.c +++ b/xen/arch/x86/mm/mem_access.c @@ -284,8 +284,7 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m, } } -return ap2m->set_entry(ap2m, gfn, mfn, PAGE_ORDER_4K, t, a, - current->domain != d); +return ap2m->set_entry(ap2m, gfn, mfn, PAGE_ORDER_4K, t, a, -1); } static int set_mem_access(struct domain *d, struct p2m_domain *p2m, -- 2.18.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4] x86/altp2m: Add a subop for obtaining the mem access of a page
Currently there is a subop for setting the memaccess of a page, but not
for consulting it. The new HVMOP_altp2m_get_mem_access adds this
functionality.
Both altp2m get/set mem access functions use the struct
xen_hvm_altp2m_mem_access which has now dropped the `set' part and has
been renamed from xen_hvm_altp2m_set_mem_access.
Signed-off-by: Adrian Pop
---
Changes in v4:
- don't break the stable interface
Changes in v3:
- remove the unrelated helper function
- simplify the locking in p2m_get_mem_access
Changes in v2:
- use the _p2m_get_mem_access helper from p2m_get_mem_access
- minor Arm adjustments
- move out the addition of a memaccess helper function to a separate
patch in the attempts of making the diff clearer
---
tools/libxc/include/xenctrl.h | 3 +++
tools/libxc/xc_altp2m.c | 33 +
xen/arch/arm/mem_access.c | 8 ++--
xen/arch/x86/hvm/hvm.c | 27 +++
xen/arch/x86/mm/mem_access.c| 21 +++--
xen/common/mem_access.c | 2 +-
xen/include/public/hvm/hvm_op.h | 19 +++
xen/include/public/xen-compat.h | 2 +-
xen/include/xen/mem_access.h| 3 ++-
9 files changed, 111 insertions(+), 7 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c626984aba..ae298899fc 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1958,6 +1958,9 @@ int xc_altp2m_set_mem_access(xc_interface *handle,
uint32_t domid,
int xc_altp2m_set_mem_access_multi(xc_interface *handle, uint32_t domid,
uint16_t view_id, uint8_t *access,
uint64_t *gfns, uint32_t nr);
+int xc_altp2m_get_mem_access(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, xen_pfn_t gfn,
+ xenmem_access_t *access);
int xc_altp2m_change_gfn(xc_interface *handle, uint32_t domid,
uint16_t view_id, xen_pfn_t old_gfn,
xen_pfn_t new_gfn);
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index ce4a1e4d60..53754ff6d3 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -177,9 +177,15 @@ int xc_altp2m_set_mem_access(xc_interface *handle,
uint32_t domid,
arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
arg->cmd = HVMOP_altp2m_set_mem_access;
arg->domain = domid;
+#if __XEN_INTERFACE_VERSION__ < 0x00040a00
arg->u.set_mem_access.view = view_id;
arg->u.set_mem_access.hvmmem_access = access;
arg->u.set_mem_access.gfn = gfn;
+#else /* __XEN_INTERFACE_VERSION__ >= 0x00040a00 */
+arg->u.mem_access.view = view_id;
+arg->u.mem_access.hvmmem_access = access;
+arg->u.mem_access.gfn = gfn;
+#endif
rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
HYPERCALL_BUFFER_AS_ARG(arg));
@@ -254,3 +260,30 @@ int xc_altp2m_set_mem_access_multi(xc_interface *xch,
uint32_t domid,
return rc;
}
+
+int xc_altp2m_get_mem_access(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, xen_pfn_t gfn,
+ xenmem_access_t *access)
+{
+int rc;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+
+arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+arg->cmd = HVMOP_altp2m_get_mem_access;
+arg->domain = domid;
+arg->u.mem_access.view = view_id;
+arg->u.mem_access.gfn = gfn;
+
+rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+ HYPERCALL_BUFFER_AS_ARG(arg));
+
+if ( !rc )
+*access = arg->u.mem_access.hvmmem_access;
+
+xc_hypercall_buffer_free(handle, arg);
+return rc;
+}
diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index ba4ec780fd..178bc1a6c1 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -236,7 +236,7 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const
struct npfec npfec)
if ( !p2m->mem_access_enabled )
return true;
-rc = p2m_get_mem_access(v->domain, gaddr_to_gfn(gpa), );
+rc = p2m_get_mem_access(v->domain, gaddr_to_gfn(gpa), , 0);
if ( rc )
return true;
@@ -441,11 +441,15 @@ long p2m_set_mem_access_multi(struct domain *d,
}
int p2m_get_mem_access(struct domain *d, gfn_t gfn,
- xenmem_access_t *access)
+ xenmem_access_t *access, unsigned int altp2m_idx)
{
int ret;
struct p2m_domain *p2m = p2m_get_hostp2m(d);
+/* altp2m is not yet implemented on Arm. The altp2m_idx should be 0. */
+if ( altp2m_idx )
+return -EINVAL;
+
p2m_read_lock(p2m);
ret = __p2m_get_mem_access(d, gfn, access);
p2m_read_unlock(p2m);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index
[Xen-devel] [PATCH v2 2/2] x86/HVM: split page straddling emulated accesses in more cases
Assuming consecutive linear addresses map to all RAM or all MMIO is not
correct. Nor is assuming that a page straddling MMIO access will access
the same emulating component for both parts of the access. If a guest
RAM read fails with HVMTRANS_bad_gfn_to_mfn and if the access straddles
a page boundary, issue accesses separately for both parts.
The extra call to known_glfn() from hvmemul_write() is just to preserve
original behavior; we should consider dropping this (also to make sure
the intended effect of 8cbd4fb0b7 ["x86/hvm: implement hvmemul_write()
using real mappings"] is achieved in all cases where it can be achieved
without further rework), or alternatively we perhaps ought to mirror
this in hvmemul_rmw().
Note that the correctness of this depends on the MMIO caching used
elsewhere in the emulation code.
Signed-off-by: Jan Beulich
---
v2: Also handle hvmemul_{write,rmw}().
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1041,6 +1041,110 @@ static inline int hvmemul_linear_mmio_wr
pfec, hvmemul_ctxt, translate);
}
+static bool known_glfn(unsigned long addr, unsigned int bytes, uint32_t pfec)
+{
+const struct hvm_vcpu_io *vio = >arch.hvm.hvm_io;
+
+if ( pfec & PFEC_write_access )
+{
+if ( !vio->mmio_access.write_access )
+return false;
+}
+else if ( pfec & PFEC_insn_fetch )
+{
+if ( !vio->mmio_access.insn_fetch )
+return false;
+}
+else if ( !vio->mmio_access.read_access )
+return false;
+
+return (vio->mmio_gla == (addr & PAGE_MASK) &&
+(addr & ~PAGE_MASK) + bytes <= PAGE_SIZE);
+}
+
+static int linear_read(unsigned long addr, unsigned int bytes, void *p_data,
+ uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt)
+{
+pagefault_info_t pfinfo;
+int rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, );
+
+switch ( rc )
+{
+unsigned int offset, part1;
+
+case HVMTRANS_okay:
+return X86EMUL_OKAY;
+
+case HVMTRANS_bad_linear_to_gfn:
+x86_emul_pagefault(pfinfo.ec, pfinfo.linear, _ctxt->ctxt);
+return X86EMUL_EXCEPTION;
+
+case HVMTRANS_bad_gfn_to_mfn:
+if ( pfec & PFEC_insn_fetch )
+return X86EMUL_UNHANDLEABLE;
+
+offset = addr & ~PAGE_MASK;
+if ( offset + bytes <= PAGE_SIZE )
+return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec,
+hvmemul_ctxt,
+known_glfn(addr, bytes, pfec));
+
+/* Split the access at the page boundary. */
+part1 = PAGE_SIZE - offset;
+rc = linear_read(addr, part1, p_data, pfec, hvmemul_ctxt);
+if ( rc == X86EMUL_OKAY )
+rc = linear_read(addr + part1, bytes - part1, p_data + part1,
+ pfec, hvmemul_ctxt);
+return rc;
+
+case HVMTRANS_gfn_paged_out:
+case HVMTRANS_gfn_shared:
+return X86EMUL_RETRY;
+}
+
+return X86EMUL_UNHANDLEABLE;
+}
+
+static int linear_write(unsigned long addr, unsigned int bytes, void *p_data,
+uint32_t pfec, struct hvm_emulate_ctxt *hvmemul_ctxt)
+{
+pagefault_info_t pfinfo;
+int rc = hvm_copy_to_guest_linear(addr, p_data, bytes, pfec, );
+
+switch ( rc )
+{
+unsigned int offset, part1;
+
+case HVMTRANS_okay:
+return X86EMUL_OKAY;
+
+case HVMTRANS_bad_linear_to_gfn:
+x86_emul_pagefault(pfinfo.ec, pfinfo.linear, _ctxt->ctxt);
+return X86EMUL_EXCEPTION;
+
+case HVMTRANS_bad_gfn_to_mfn:
+offset = addr & ~PAGE_MASK;
+if ( offset + bytes <= PAGE_SIZE )
+return hvmemul_linear_mmio_write(addr, bytes, p_data, pfec,
+ hvmemul_ctxt,
+ known_glfn(addr, bytes, pfec));
+
+/* Split the access at the page boundary. */
+part1 = PAGE_SIZE - offset;
+rc = linear_write(addr, part1, p_data, pfec, hvmemul_ctxt);
+if ( rc == X86EMUL_OKAY )
+rc = linear_write(addr + part1, bytes - part1, p_data + part1,
+ pfec, hvmemul_ctxt);
+return rc;
+
+case HVMTRANS_gfn_paged_out:
+case HVMTRANS_gfn_shared:
+return X86EMUL_RETRY;
+}
+
+return X86EMUL_UNHANDLEABLE;
+}
+
static int __hvmemul_read(
enum x86_segment seg,
unsigned long offset,
@@ -1049,11 +1153,8 @@ static int __hvmemul_read(
enum hvm_access_type access_type,
struct hvm_emulate_ctxt *hvmemul_ctxt)
{
-struct vcpu *curr = current;
-pagefault_info_t pfinfo;
unsigned long addr, reps = 1;
uint32_t pfec = PFEC_page_present;
-struct hvm_vcpu_io *vio = >arch.hvm.hvm_io;
int rc;
if ( is_x86_system_segment(seg) )
@@ -1067,34 +1168,8 @@ static int __hvmemul_read(
seg, offset, bytes, ,
[Xen-devel] [PATCH v2 1/2] x86/HVM: drop hvm_fetch_from_guest_linear()
It can easily be expressed through hvm_copy_from_guest_linear(), and in
two cases this even simplifies callers.
Suggested-by: Paul Durrant
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Make sure this compiles standalone. Slightly adjust change in
hvm_ud_intercept().
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1060,6 +1060,8 @@ static int __hvmemul_read(
pfec |= PFEC_implicit;
else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 )
pfec |= PFEC_user_mode;
+if ( access_type == hvm_access_insn_fetch )
+pfec |= PFEC_insn_fetch;
rc = hvmemul_virtual_to_linear(
seg, offset, bytes, , access_type, hvmemul_ctxt, );
@@ -1071,9 +1073,7 @@ static int __hvmemul_read(
(vio->mmio_gla == (addr & PAGE_MASK)) )
return hvmemul_linear_mmio_read(addr, bytes, p_data, pfec,
hvmemul_ctxt, 1);
-rc = ((access_type == hvm_access_insn_fetch) ?
- hvm_fetch_from_guest_linear(p_data, addr, bytes, pfec, ) :
- hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, ));
+rc = hvm_copy_from_guest_linear(p_data, addr, bytes, pfec, );
switch ( rc )
{
@@ -2512,9 +2512,10 @@ void hvm_emulate_init_per_insn(
hvm_access_insn_fetch,
_ctxt->seg_reg[x86_seg_cs],
) &&
- hvm_fetch_from_guest_linear(hvmemul_ctxt->insn_buf, addr,
- sizeof(hvmemul_ctxt->insn_buf),
- pfec, NULL) == HVMTRANS_okay) ?
+ hvm_copy_from_guest_linear(hvmemul_ctxt->insn_buf, addr,
+sizeof(hvmemul_ctxt->insn_buf),
+pfec | PFEC_insn_fetch,
+NULL) == HVMTRANS_okay) ?
sizeof(hvmemul_ctxt->insn_buf) : 0;
}
else
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3287,15 +3287,6 @@ enum hvm_translation_result hvm_copy_fro
PFEC_page_present | pfec, pfinfo);
}
-enum hvm_translation_result hvm_fetch_from_guest_linear(
-void *buf, unsigned long addr, int size, uint32_t pfec,
-pagefault_info_t *pfinfo)
-{
-return __hvm_copy(buf, addr, size, current,
- HVMCOPY_from_guest | HVMCOPY_linear,
- PFEC_page_present | PFEC_insn_fetch | pfec, pfinfo);
-}
-
unsigned long copy_to_user_hvm(void *to, const void *from, unsigned int len)
{
int rc;
@@ -3741,16 +3732,16 @@ void hvm_ud_intercept(struct cpu_user_re
if ( opt_hvm_fep )
{
const struct segment_register *cs = _reg[x86_seg_cs];
-uint32_t walk = (ctxt.seg_reg[x86_seg_ss].dpl == 3)
-? PFEC_user_mode : 0;
+uint32_t walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3)
+ ? PFEC_user_mode : 0) | PFEC_insn_fetch;
unsigned long addr;
char sig[5]; /* ud2; .ascii "xen" */
if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip,
sizeof(sig), hvm_access_insn_fetch,
cs, ) &&
- (hvm_fetch_from_guest_linear(sig, addr, sizeof(sig),
- walk, NULL) == HVMTRANS_okay) &&
+ (hvm_copy_from_guest_linear(sig, addr, sizeof(sig),
+ walk, NULL) == HVMTRANS_okay) &&
(memcmp(sig, "\xf\xbxen", sizeof(sig)) == 0) )
{
regs->rip += sizeof(sig);
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -164,8 +164,9 @@ const struct x86_emulate_ops *shadow_ini
(!hvm_translate_virtual_addr(
x86_seg_cs, regs->rip, sizeof(sh_ctxt->insn_buf),
hvm_access_insn_fetch, sh_ctxt, ) &&
- !hvm_fetch_from_guest_linear(
- sh_ctxt->insn_buf, addr, sizeof(sh_ctxt->insn_buf), 0, NULL))
+ !hvm_copy_from_guest_linear(
+ sh_ctxt->insn_buf, addr, sizeof(sh_ctxt->insn_buf),
+ PFEC_insn_fetch, NULL))
? sizeof(sh_ctxt->insn_buf) : 0;
return _shadow_emulator_ops;
@@ -198,8 +199,9 @@ void shadow_continue_emulation(struct sh
(!hvm_translate_virtual_addr(
x86_seg_cs, regs->rip, sizeof(sh_ctxt->insn_buf),
hvm_access_insn_fetch, sh_ctxt, ) &&
- !hvm_fetch_from_guest_linear(
- sh_ctxt->insn_buf, addr, sizeof(sh_ctxt->insn_buf), 0, NULL))
+ !hvm_copy_from_guest_linear(
+ sh_ctxt->insn_buf, addr, sizeof(sh_ctxt->insn_buf),
+ PFEC_insn_fetch, NULL))
? sizeof(sh_ctxt->insn_buf) : 0;
sh_ctxt->insn_buf_eip = regs->rip;
}
--- a/xen/arch/x86/mm/shadow/hvm.c
+++ b/xen/arch/x86/mm/shadow/hvm.c
@@ -122,10 +122,10 @@ hvm_read(enum
[Xen-devel] [PATCH v2 0/2] x86/HVM: emulation adjustments
1: drop hvm_fetch_from_guest_linear() 2: split page straddling emulated accesses in more cases v2: Patch 1 now builds cleanly (without other patches in place the up-to- date versions of which are yet to be posted), and patch 2 is no longer RFC. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] pvshim: introduce a PV shim defconfig
In order to build a tailored pvshim-only binary from Xen. Switch the PV shim build from the tools firmware into using the new defconfig. A diff of the .config generated for the pvshim firmware build before and after this change shows no differences. Signed-off-by: Roger Pau Monné Acked-by: Ian Jackson Acked-by: Wei Liu --- Cc: Ian Jackson Cc: Wei Liu Cc: Jan Beulich Cc: Andrew Cooper --- Changes since v1: - Use '# CONFIG_X is not set' instead of CONFIG_X=n. --- tools/firmware/xen-dir/Makefile | 5 +- tools/firmware/xen-dir/shim.config| 84 --- xen/arch/x86/configs/pvshim_defconfig | 23 3 files changed, 25 insertions(+), 87 deletions(-) delete mode 100644 tools/firmware/xen-dir/shim.config create mode 100644 xen/arch/x86/configs/pvshim_defconfig diff --git a/tools/firmware/xen-dir/Makefile b/tools/firmware/xen-dir/Makefile index 84648c3faf..83597f0017 100644 --- a/tools/firmware/xen-dir/Makefile +++ b/tools/firmware/xen-dir/Makefile @@ -41,9 +41,8 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE $(D): linkfarm.stamp $(MAKE) -C $(D)/xen distclean -$(D)/xen/.config: shim.config $(D) - cp $< $@ - $(MAKE) -C $(@D) olddefconfig XEN_CONFIG_EXPERT=y +$(D)/xen/.config: $(D) + $(MAKE) -C $(@D) KBUILD_DEFCONFIG=pvshim_defconfig XEN_CONFIG_EXPERT=y defconfig xen-shim: $(D)/xen/.config $(MAKE) -C $(https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] hvmloader: fix build with LLVM Linker
On Mon, Sep 03, 2018 at 05:33:26PM +0200, Roger Pau Monne wrote: > The hvmloader binary generated when using LLVM LD doesn't work > properly and seems to get stuck while trying to generate and load the > ACPI tables. This is caused by the layout of the binary when linked > with LLVM LD. > > LLVM LD has a different default linker script that GNU LD, and the > resulting hvmloader binary is slightly different: > > LLVM LD: > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > PHDR 0x34 0x000ff034 0x000ff034 0x00060 0x00060 R 0x4 > LOAD 0x00 0x000ff000 0x000ff000 0x38000 0x38000 RWE 0x1000 > GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0 > > GNU LD: > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x80 0x0010 0x0010 0x36308 0x3fd74 RWE 0x10 > GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x4 > > Note that in the LLVM LD case (as with GNU LD) the .text section does > indeed have the address set to 0x10 as requested on the command > line: > > [ 1] .text PROGBITS0010 001000 00dd10 00 AX 0 0 16 > > There's however the PHDR which is not present when using GNU LD. > > Fix this by using a very simple linker script that generates the same > binary regardless of whether LLVM or GNU LD is used. By using a linker > script the usage of -Ttext can also be avoided by placing the desired > .text load address directly in the linker script. > > Signed-off-by: Roger Pau Monné Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] hvmloader: fix build with LLVM Linker
The hvmloader binary generated when using LLVM LD doesn't work
properly and seems to get stuck while trying to generate and load the
ACPI tables. This is caused by the layout of the binary when linked
with LLVM LD.
LLVM LD has a different default linker script that GNU LD, and the
resulting hvmloader binary is slightly different:
LLVM LD:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x34 0x000ff034 0x000ff034 0x00060 0x00060 R 0x4
LOAD 0x00 0x000ff000 0x000ff000 0x38000 0x38000 RWE 0x1000
GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0
GNU LD:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x80 0x0010 0x0010 0x36308 0x3fd74 RWE 0x10
GNU_STACK 0x00 0x 0x 0x0 0x0 RW 0x4
Note that in the LLVM LD case (as with GNU LD) the .text section does
indeed have the address set to 0x10 as requested on the command
line:
[ 1] .text PROGBITS0010 001000 00dd10 00 AX 0 0 16
There's however the PHDR which is not present when using GNU LD.
Fix this by using a very simple linker script that generates the same
binary regardless of whether LLVM or GNU LD is used. By using a linker
script the usage of -Ttext can also be avoided by placing the desired
.text load address directly in the linker script.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Ian Jackson
---
Changes since v1:
- Also add ..*.
---
tools/firmware/hvmloader/Makefile | 7 ++-
tools/firmware/hvmloader/hvmloader.lds | 13 +
2 files changed, 15 insertions(+), 5 deletions(-)
create mode 100644 tools/firmware/hvmloader/hvmloader.lds
diff --git a/tools/firmware/hvmloader/Makefile
b/tools/firmware/hvmloader/Makefile
index 496ac72b77..e980ce7c5f 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,9 +20,6 @@
XEN_ROOT = $(CURDIR)/../../..
include $(XEN_ROOT)/tools/firmware/Rules.mk
-
-LOADADDR = 0x10
-
# SMBIOS spec requires format mm/dd/
SMBIOS_REL_DATE ?= $(shell date +%m/%d/%Y)
@@ -82,8 +79,8 @@ vpath build.c $(ACPI_PATH)
vpath static_tables.c $(ACPI_PATH)
OBJS += $(ACPI_OBJS)
-hvmloader: $(OBJS)
- $(LD) $(LDFLAGS_DIRECT) -N -Ttext $(LOADADDR) -o $@ $^
+hvmloader: $(OBJS) hvmloader.lds
+ $(LD) $(LDFLAGS_DIRECT) -N -T hvmloader.lds -o $@ $(OBJS)
roms.inc: $(ROMS)
echo "/* Autogenerated file. DO NOT EDIT */" > $@.new
diff --git a/tools/firmware/hvmloader/hvmloader.lds
b/tools/firmware/hvmloader/hvmloader.lds
new file mode 100644
index 00..4471d7af27
--- /dev/null
+++ b/tools/firmware/hvmloader/hvmloader.lds
@@ -0,0 +1,13 @@
+SECTIONS
+{
+ . = 0x10;
+ /*
+ * NB: there's no need to use the AT keyword in order to set the LMA, by
+ * default the linker will use VMA = LMA unless specified otherwise.
+ */
+ .text : { *(.text) *(.text.*) }
+ .rodata : { *(.rodata) *(.rodata.*) }
+ .data : { *(.data) *(.data.*) }
+ .bss : { *(.bss) *(.bss.*) }
+ _end = .;
+}
--
2.18.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/1] cameraif: add ABI for para-virtual camera
Hi Oleksandr, On 09/03/2018 12:16 PM, Oleksandr Andrushchenko wrote: > On 08/21/2018 08:54 AM, Oleksandr Andrushchenko wrote: >> On 08/14/2018 11:30 AM, Juergen Gross wrote: >>> On 31/07/18 11:31, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This is the ABI for the two halves of a para-virtualized camera driver which extends Xen's reach multimedia capabilities even farther enabling it for video conferencing, In-Vehicle Infotainment, high definition maps etc. The initial goal is to support most needed functionality with the final idea to make it possible to extend the protocol if need be: 1. Provide means for base virtual device configuration: - pixel formats - resolutions - frame rates 2. Support basic camera controls: - contrast - brightness - hue - saturation 3. Support streaming control 4. Support zero-copying use-cases Signed-off-by: Oleksandr Andrushchenko >>> Some style issues below... >> Will fix all the below, thank you! >> >> I would like to draw some attention of the Linux/V4L community to this >> protocol as the plan is that once it is accepted for Xen we plan to >> upstream a Linux camera front-end kernel driver which will be based >> on this work and will be a V4L2 device driver (this is why I have sent >> this patch not only to Xen, but to the corresponding Linux mailing list >> as well) > ping Sorry, this got buried in my mailbox, I only came across it today. I'll try to review this this week, if not, just ping me again. I had one high-level question, though: What types of hardware do you intend to target? This initial version targets (very) simple webcams, but what about HDMI or SDTV receivers? Or hardware codecs? Or complex embedded video pipelines? In other words, where are you planning to draw the line? Even with just simple cameras there is a difference between regular UVC webcams and cameras used with embedded systems: for the latter you often need to provide more control w.r.t. white-balancing etc., things that a UVC webcam will generally do for you in the webcam's firmware. Regards, Hans ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 127070: regressions - FAIL
On 03/09/18 17:21, Jan Beulich wrote: On 03.09.18 at 14:56, wrote: >> On 03/09/18 14:44, Jan Beulich wrote: >> On 01.09.18 at 23:43, wrote: flight 127070 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/127070/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail REGR. vs. >> 126854 >>> >>> I wonder if this >>> >>> [ 30.017142] BUG: unable to handle kernel paging request at 0002ffa8 >>> [ 30.017208] IP: __radix_tree_lookup+0x12/0xb0 >>> [ 30.017235] *pdpt = 1eca5027 *pde = >>> [ 30.017271] Oops: [#1] SMP >>> [ 30.017293] Modules linked in: ext4 mbcache jbd2 >>> [ 30.017352] CPU: 2 PID: 1204 Comm: systemd Not tainted 4.14.67+ #1 >>> [ 30.017383] task: df601f80 task.stack: dafd8000 >>> [ 30.017411] EIP: __radix_tree_lookup+0x12/0xb0 >>> [ 30.017445] EFLAGS: 00010282 CPU: 2 >>> [ 30.017468] EAX: 0002ffa4 EBX: b7ed2000 ECX: EDX: 01ff >>> [ 30.017503] ESI: EDI: EBP: dafd9de4 ESP: dafd9dd0 >>> [ 30.017534] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 >>> [ 30.017571] CR0: 80050033 CR2: 0002ffa8 CR3: 1eca4000 CR4: 00042660 >>> [ 30.017620] Call Trace: >>> [ 30.017642] radix_tree_lookup_slot+0x11/0x30 >>> [ 30.017673] ? xen_set_pud+0xa0/0xa0 >>> [ 30.017699] find_get_entry+0x1d/0x110 >>> [ 30.017723] pagecache_get_page+0x1f/0x230 >>> [ 30.017752] lookup_swap_cache+0x35/0x110 >>> [ 30.017778] swap_readahead_detect+0x84/0x2f0 >>> [ 30.017809] do_swap_page+0x25b/0x8e0 >>> [ 30.017837] ? wp_page_copy+0x399/0x6b0 >>> [ 30.017866] ? kmap_atomic_prot+0x2b/0x180 >>> [ 30.017892] ? __raw_callee_save_xen_pte_val+0xc/0xc >>> [ 30.017925] handle_mm_fault+0x468/0x9e0 >>> [ 30.017951] __do_page_fault+0x1ba/0x4e0 >>> [ 30.017976] ? __do_page_fault+0x4e0/0x4e0 >>> [ 30.018008] do_page_fault+0x37/0x100 >>> [ 30.018032] ? __do_page_fault+0x4e0/0x4e0 >>> [ 30.018060] common_exception+0x77/0x7e >>> [ 30.018084] EIP: 0xb7f0d39f >>> [ 30.018101] EFLAGS: 00010246 CPU: 2 >>> [ 30.018124] EAX: b7ed2030 EBX: b7f2 ECX: b7bf91b8 EDX: 0002 >>> [ 30.018158] ESI: b7f2055c EDI: b7f10e90 EBP: b7bf9260 ESP: b7bf9208 >>> [ 30.018190] DS: 007b ES: 007b FS: GS: 0033 SS: 007b >>> [ 30.018220] ? __do_page_fault+0x4e0/0x4e0 >>> [ 30.018242] Code: 00 8b 03 c1 e8 1a 85 c0 74 be 0f 0b 8d b6 00 00 00 00 >> 8d bc 27 00 00 00 00 55 89 e5 57 56 53 83 ec 08 89 45 f0 89 4d ec 8b 45 f0 >> <8b> >> 40 04 89 c1 83 e1 03 83 f9 01 75 71 89 c1 bf 40 00 00 00 83 >>> [ 30.018415] EIP: __radix_tree_lookup+0x12/0xb0 SS:ESP: 0069:dafd9dd0 >>> [ 30.018445] CR2: 0002ffa8 >>> [ 30.018472] ---[ end trace c8ba97a241bb2040 ]--- >>> >>> isn't a (presumably indirect) result of >>> >>> Sep 1 03:06:32.180094 (XEN) d28 L1TF-vulnerable L1e 8004 - >> Shadowing >>> >>> Jürgen's change to avoid split PTE writes would then only be >>> papering over an active issue. >> >> No, it isn't papering over the issue, but repairing it. See >> >> https://bugzilla.kernel.org/show_bug.cgi?id=198497 >> >> which clearly states that this issue has been seen on bare metal, too. >> On Xen its just much more frequent as the timing is different. > > Hmm, yes - if the problem exists also on native, then while your fix is > hiding that problem, it's not one in Xen code. Question though is how > valuable this particular test is until the fix has trickled in on the Linux > side. I'm about to request the patch to be included in stable kernels. To be more explicit why the patch is fixing the problem: native_ptep_get_and_clear() is thought to get the old pte contents and clear the pte atomically. While the implementation via 32-bit operations was fine regarding races against other updates it was not fine regarding read accesses after having written the low word and before clearing the high word: a page fault would detect a non-zero value in the high word and assume the data being present on some swap device. My patch now removes this possible race and the problem can't occur any longer. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] tools/libxl: Switch Arm guest type to PVH
On Mon, Sep 03, 2018 at 12:11:27PM +0100, Julien Grall wrote: > I don't think so. The top makefile does not pass -DCONFIG_ARM on compiler > command line. This is only done in sub-directory such as console and > libacpi. Indeed. That how console code did it. > > > > > There are several CONFIG_ARM* in toolstack code, though not in libxl. In > > any case, I think the code is fine as-is. > > I am happy to introduce CONFIG_ARM/CONFIG_X86 if you don't mind adding > -DCONFIG_ARM on the command line. I'm not too fussed. Keeping your code as-is is fine. Wei. > > Cheers, > > -- > Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [xen-unstable test] 127070: regressions - FAIL
>>> On 03.09.18 at 14:56, wrote: > On 03/09/18 14:44, Jan Beulich wrote: > On 01.09.18 at 23:43, wrote: >>> flight 127070 xen-unstable real [real] >>> http://logs.test-lab.xenproject.org/osstest/logs/127070/ >>> >>> Regressions :-( >>> >>> Tests which did not succeed and are blocking, >>> including tests which could not be run: >>> test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail REGR. vs. > 126854 >> >> I wonder if this >> >> [ 30.017142] BUG: unable to handle kernel paging request at 0002ffa8 >> [ 30.017208] IP: __radix_tree_lookup+0x12/0xb0 >> [ 30.017235] *pdpt = 1eca5027 *pde = >> [ 30.017271] Oops: [#1] SMP >> [ 30.017293] Modules linked in: ext4 mbcache jbd2 >> [ 30.017352] CPU: 2 PID: 1204 Comm: systemd Not tainted 4.14.67+ #1 >> [ 30.017383] task: df601f80 task.stack: dafd8000 >> [ 30.017411] EIP: __radix_tree_lookup+0x12/0xb0 >> [ 30.017445] EFLAGS: 00010282 CPU: 2 >> [ 30.017468] EAX: 0002ffa4 EBX: b7ed2000 ECX: EDX: 01ff >> [ 30.017503] ESI: EDI: EBP: dafd9de4 ESP: dafd9dd0 >> [ 30.017534] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 >> [ 30.017571] CR0: 80050033 CR2: 0002ffa8 CR3: 1eca4000 CR4: 00042660 >> [ 30.017620] Call Trace: >> [ 30.017642] radix_tree_lookup_slot+0x11/0x30 >> [ 30.017673] ? xen_set_pud+0xa0/0xa0 >> [ 30.017699] find_get_entry+0x1d/0x110 >> [ 30.017723] pagecache_get_page+0x1f/0x230 >> [ 30.017752] lookup_swap_cache+0x35/0x110 >> [ 30.017778] swap_readahead_detect+0x84/0x2f0 >> [ 30.017809] do_swap_page+0x25b/0x8e0 >> [ 30.017837] ? wp_page_copy+0x399/0x6b0 >> [ 30.017866] ? kmap_atomic_prot+0x2b/0x180 >> [ 30.017892] ? __raw_callee_save_xen_pte_val+0xc/0xc >> [ 30.017925] handle_mm_fault+0x468/0x9e0 >> [ 30.017951] __do_page_fault+0x1ba/0x4e0 >> [ 30.017976] ? __do_page_fault+0x4e0/0x4e0 >> [ 30.018008] do_page_fault+0x37/0x100 >> [ 30.018032] ? __do_page_fault+0x4e0/0x4e0 >> [ 30.018060] common_exception+0x77/0x7e >> [ 30.018084] EIP: 0xb7f0d39f >> [ 30.018101] EFLAGS: 00010246 CPU: 2 >> [ 30.018124] EAX: b7ed2030 EBX: b7f2 ECX: b7bf91b8 EDX: 0002 >> [ 30.018158] ESI: b7f2055c EDI: b7f10e90 EBP: b7bf9260 ESP: b7bf9208 >> [ 30.018190] DS: 007b ES: 007b FS: GS: 0033 SS: 007b >> [ 30.018220] ? __do_page_fault+0x4e0/0x4e0 >> [ 30.018242] Code: 00 8b 03 c1 e8 1a 85 c0 74 be 0f 0b 8d b6 00 00 00 00 > 8d bc 27 00 00 00 00 55 89 e5 57 56 53 83 ec 08 89 45 f0 89 4d ec 8b 45 f0 > <8b> > 40 04 89 c1 83 e1 03 83 f9 01 75 71 89 c1 bf 40 00 00 00 83 >> [ 30.018415] EIP: __radix_tree_lookup+0x12/0xb0 SS:ESP: 0069:dafd9dd0 >> [ 30.018445] CR2: 0002ffa8 >> [ 30.018472] ---[ end trace c8ba97a241bb2040 ]--- >> >> isn't a (presumably indirect) result of >> >> Sep 1 03:06:32.180094 (XEN) d28 L1TF-vulnerable L1e 8004 - > Shadowing >> >> Jürgen's change to avoid split PTE writes would then only be >> papering over an active issue. > > No, it isn't papering over the issue, but repairing it. See > > https://bugzilla.kernel.org/show_bug.cgi?id=198497 > > which clearly states that this issue has been seen on bare metal, too. > On Xen its just much more frequent as the timing is different. Hmm, yes - if the problem exists also on native, then while your fix is hiding that problem, it's not one in Xen code. Question though is how valuable this particular test is until the fix has trickled in on the Linux side. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] add cpu_thread_id to struct cpuinfo_x86
>>> On 03.09.18 at 17:11, wrote:
> On 03/09/18 17:07, Jan Beulich wrote:
> On 03.09.18 at 16:52, wrote:
>>> On 03/09/18 16:47, Jan Beulich wrote:
>>> On 03.09.18 at 15:53, wrote:
> On 03/09/18 15:46, Jan Beulich wrote:
> On 31.08.18 at 18:22, wrote:
>>> Add the thread-id to the cpu config data and an accessor macro
>>> cpu_to_thread().
>>>
>>> Signed-off-by: Juergen Gross
>>> ---
>>> xen/arch/x86/cpu/common.c | 1 +
>>> xen/arch/x86/smpboot.c | 10 ++
>>> xen/include/asm-arm/processor.h | 1 +
>>> xen/include/asm-x86/processor.h | 2 ++
>>> xen/include/public/sysctl.h | 1 +
>>> 5 files changed, 15 insertions(+)
>>>
>>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>>> index 057859ab14..f626a6a510 100644
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -434,6 +434,7 @@ void identify_cpu(struct cpuinfo_x86 *c)
>>> c->phys_proc_id = XEN_INVALID_SOCKET_ID;
>>> c->cpu_core_id = XEN_INVALID_CORE_ID;
>>> c->compute_unit_id = INVALID_CUID;
>>> + c->cpu_thread_id = XEN_INVALID_THREAD_ID;
>>> memset(>x86_capability, 0, sizeof c->x86_capability);
>>>
>>> generic_identify(c);
>>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>>> index 7e76cc3d68..2c6a40c543 100644
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -247,6 +247,8 @@ static void set_cpu_sibling_map(unsigned int cpu)
>>> cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
>>> cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>>>
>>> +c[cpu].cpu_thread_id = 0;
>>> +
>>> if ( c[cpu].x86_num_siblings > 1 )
>>> {
>>> for_each_cpu ( i, _sibling_setup_map )
>>> @@ -270,6 +272,14 @@ static void set_cpu_sibling_map(unsigned int cpu)
>>> "CPU%u: unclear relationship with CPU%u\n",
>>> cpu, i);
>>> }
>>> +
>>> +for_each_cpu ( i, per_cpu(cpu_sibling_mask, cpu) )
>>> +{
>>> +if ( cpu == i )
>>> +break;
>>> +c[cpu].cpu_thread_id++;
>>
>> No. This wants doing alongside setting of the other similar fields,
>> i.e. in (at least) detect_extended_topology() and detect_ht(). It
>> is the hardware which tells us what the thread ID is.
>
> I wasn't able to find the related information for AMD cpus. In case it
> is in the specs it is hidden very well.
What was used for compute units in Fam16 and earlier is used for
hyperthreads in Fam17 (and going forward, from what iirc Brian
has said).
>>>
>>> And what about hyperthreads in Fam16 and earlier? Or are "compute units"
>>> just another name for the threads and I can rename that field?
>>
>> When there are compute units, there are no threads. But the difference
>> is more than just the names, so folding the fields is not a good idea imo.
>
> So another flag and display the column title accordingly?
>
> I'd put thread and compute unit in a union then.
Both fine with me.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/6] x86/mm: use optional cache in guest_walk_tables()
>>> On 19.07.18 at 15:22, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 19 July 2018 11:47
>>
>> @@ -134,7 +135,15 @@ guest_walk_tables(struct vcpu *v, struct
>> /* Get the l4e from the top level table and check its flags*/
>> gw->l4mfn = top_mfn;
>> l4p = (guest_l4e_t *) top_map;
>> -gw->l4e = l4p[guest_l4_table_offset(gla)];
>> +gpa = gfn_to_gaddr(top_gfn) +
>> + guest_l4_table_offset(gla) * sizeof(guest_l4e_t);
>> +if ( !cache ||
>> + !hvmemul_read_cache(cache, gpa, 4, >l4e, sizeof(gw->l4e)) )
>> +{
>> +gw->l4e = l4p[guest_l4_table_offset(gla)];
>> +if ( cache )
>> +hvmemul_write_cache(cache, gpa, 4, >l4e, sizeof(gw->l4e));
>> +}
>> gflags = guest_l4e_get_flags(gw->l4e);
>> if ( !(gflags & _PAGE_PRESENT) )
>> goto out;
>> @@ -164,7 +173,15 @@ guest_walk_tables(struct vcpu *v, struct
>> }
>>
>> /* Get the l3e and check its flags*/
>> -gw->l3e = l3p[guest_l3_table_offset(gla)];
>> +gpa = gfn_to_gaddr(guest_l4e_get_gfn(gw->l4e)) +
>> + guest_l3_table_offset(gla) * sizeof(guest_l3e_t);
>> +if ( !cache ||
>> + !hvmemul_read_cache(cache, gpa, 3, >l3e, sizeof(gw->l3e)) )
>> +{
>> +gw->l3e = l3p[guest_l3_table_offset(gla)];
>> +if ( cache )
>> +hvmemul_write_cache(cache, gpa, 3, >l3e, sizeof(gw->l3e));
>> +}
>> gflags = guest_l3e_get_flags(gw->l3e);
>> if ( !(gflags & _PAGE_PRESENT) )
>> goto out;
>> @@ -216,7 +233,16 @@ guest_walk_tables(struct vcpu *v, struct
>> #else /* PAE only... */
>>
>> /* Get the l3e and check its flag */
>> -gw->l3e = ((guest_l3e_t *)top_map)[guest_l3_table_offset(gla)];
>> +gpa = gfn_to_gaddr(top_gfn) + ((unsigned long)top_map &
>> ~PAGE_MASK) +
>> + guest_l3_table_offset(gla) * sizeof(guest_l3e_t);
>> +if ( !cache ||
>> + !hvmemul_read_cache(cache, gpa, 3, >l3e, sizeof(gw->l3e)) )
>> +{
>> +gw->l3e = ((guest_l3e_t *)top_map)[guest_l3_table_offset(gla)];
>> +if ( cache )
>> +hvmemul_write_cache(cache, gpa, 3, >l3e, sizeof(gw->l3e));
>> +}
>> +
>> gflags = guest_l3e_get_flags(gw->l3e);
>> if ( !(gflags & _PAGE_PRESENT) )
>> goto out;
>> @@ -242,18 +268,24 @@ guest_walk_tables(struct vcpu *v, struct
>> goto out;
>> }
>>
>> -/* Get the l2e */
>> -gw->l2e = l2p[guest_l2_table_offset(gla)];
>> -
>> #else /* 32-bit only... */
>>
>> -/* Get l2e from the top level table */
>> gw->l2mfn = top_mfn;
>> l2p = (guest_l2e_t *) top_map;
>> -gw->l2e = l2p[guest_l2_table_offset(gla)];
>>
>> #endif /* All levels... */
>>
>> +/* Get the l2e */
>> +gpa = gfn_to_gaddr(top_gfn) +
>> + guest_l2_table_offset(gla) * sizeof(guest_l2e_t);
>> +if ( !cache ||
>> + !hvmemul_read_cache(cache, gpa, 2, >l2e, sizeof(gw->l2e)) )
>> +{
>> +gw->l2e = l2p[guest_l2_table_offset(gla)];
>> +if ( cache )
>> +hvmemul_write_cache(cache, gpa, 2, >l2e, sizeof(gw->l2e));
>> +}
>> +
>> /* Check the l2e flags. */
>> gflags = guest_l2e_get_flags(gw->l2e);
>> if ( !(gflags & _PAGE_PRESENT) )
>> @@ -335,7 +367,17 @@ guest_walk_tables(struct vcpu *v, struct
>> gw->pfec |= rc & PFEC_synth_mask;
>> goto out;
>> }
>> -gw->l1e = l1p[guest_l1_table_offset(gla)];
>> +
>> +gpa = gfn_to_gaddr(top_gfn) +
>> + guest_l1_table_offset(gla) * sizeof(guest_l1e_t);
>> +if ( !cache ||
>> + !hvmemul_read_cache(cache, gpa, 1, >l1e, sizeof(gw->l1e)) )
>> +{
>> +gw->l1e = l1p[guest_l1_table_offset(gla)];
>> +if ( cache )
>> +hvmemul_write_cache(cache, gpa, 1, >l1e, sizeof(gw->l1e));
>> +}
>> +
>> gflags = guest_l1e_get_flags(gw->l1e);
>> if ( !(gflags & _PAGE_PRESENT) )
>> goto out;
I've just now realized that the cache writes should either be repeated
after having set A/D bits, or the setting of A/D bits should be suppressed
when a read has hit the cache. The latter option would be somewhat
difficult with our late setting of the bits, but I still wanted to ask: Do you
have a preference either way?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] add cpu_thread_id to struct cpuinfo_x86
On 03/09/18 17:07, Jan Beulich wrote:
On 03.09.18 at 16:52, wrote:
>> On 03/09/18 16:47, Jan Beulich wrote:
>> On 03.09.18 at 15:53, wrote:
On 03/09/18 15:46, Jan Beulich wrote:
On 31.08.18 at 18:22, wrote:
>> Add the thread-id to the cpu config data and an accessor macro
>> cpu_to_thread().
>>
>> Signed-off-by: Juergen Gross
>> ---
>> xen/arch/x86/cpu/common.c | 1 +
>> xen/arch/x86/smpboot.c | 10 ++
>> xen/include/asm-arm/processor.h | 1 +
>> xen/include/asm-x86/processor.h | 2 ++
>> xen/include/public/sysctl.h | 1 +
>> 5 files changed, 15 insertions(+)
>>
>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>> index 057859ab14..f626a6a510 100644
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -434,6 +434,7 @@ void identify_cpu(struct cpuinfo_x86 *c)
>> c->phys_proc_id = XEN_INVALID_SOCKET_ID;
>> c->cpu_core_id = XEN_INVALID_CORE_ID;
>> c->compute_unit_id = INVALID_CUID;
>> +c->cpu_thread_id = XEN_INVALID_THREAD_ID;
>> memset(>x86_capability, 0, sizeof c->x86_capability);
>>
>> generic_identify(c);
>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>> index 7e76cc3d68..2c6a40c543 100644
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -247,6 +247,8 @@ static void set_cpu_sibling_map(unsigned int cpu)
>> cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
>> cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>>
>> +c[cpu].cpu_thread_id = 0;
>> +
>> if ( c[cpu].x86_num_siblings > 1 )
>> {
>> for_each_cpu ( i, _sibling_setup_map )
>> @@ -270,6 +272,14 @@ static void set_cpu_sibling_map(unsigned int cpu)
>> "CPU%u: unclear relationship with CPU%u\n",
>> cpu, i);
>> }
>> +
>> +for_each_cpu ( i, per_cpu(cpu_sibling_mask, cpu) )
>> +{
>> +if ( cpu == i )
>> +break;
>> +c[cpu].cpu_thread_id++;
>
> No. This wants doing alongside setting of the other similar fields,
> i.e. in (at least) detect_extended_topology() and detect_ht(). It
> is the hardware which tells us what the thread ID is.
I wasn't able to find the related information for AMD cpus. In case it
is in the specs it is hidden very well.
>>>
>>> What was used for compute units in Fam16 and earlier is used for
>>> hyperthreads in Fam17 (and going forward, from what iirc Brian
>>> has said).
>>
>> And what about hyperthreads in Fam16 and earlier? Or are "compute units"
>> just another name for the threads and I can rename that field?
>
> When there are compute units, there are no threads. But the difference
> is more than just the names, so folding the fields is not a good idea imo.
So another flag and display the column title accordingly?
I'd put thread and compute unit in a union then.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] add cpu_thread_id to struct cpuinfo_x86
On 03/09/18 15:52, Juergen Gross wrote:
> On 03/09/18 16:47, Jan Beulich wrote:
> On 03.09.18 at 15:53, wrote:
>>> On 03/09/18 15:46, Jan Beulich wrote:
>>> On 31.08.18 at 18:22, wrote:
> Add the thread-id to the cpu config data and an accessor macro
> cpu_to_thread().
>
> Signed-off-by: Juergen Gross
> ---
> xen/arch/x86/cpu/common.c | 1 +
> xen/arch/x86/smpboot.c | 10 ++
> xen/include/asm-arm/processor.h | 1 +
> xen/include/asm-x86/processor.h | 2 ++
> xen/include/public/sysctl.h | 1 +
> 5 files changed, 15 insertions(+)
>
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index 057859ab14..f626a6a510 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -434,6 +434,7 @@ void identify_cpu(struct cpuinfo_x86 *c)
> c->phys_proc_id = XEN_INVALID_SOCKET_ID;
> c->cpu_core_id = XEN_INVALID_CORE_ID;
> c->compute_unit_id = INVALID_CUID;
> + c->cpu_thread_id = XEN_INVALID_THREAD_ID;
> memset(>x86_capability, 0, sizeof c->x86_capability);
>
> generic_identify(c);
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 7e76cc3d68..2c6a40c543 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -247,6 +247,8 @@ static void set_cpu_sibling_map(unsigned int cpu)
> cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
> cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>
> +c[cpu].cpu_thread_id = 0;
> +
> if ( c[cpu].x86_num_siblings > 1 )
> {
> for_each_cpu ( i, _sibling_setup_map )
> @@ -270,6 +272,14 @@ static void set_cpu_sibling_map(unsigned int cpu)
> "CPU%u: unclear relationship with CPU%u\n",
> cpu, i);
> }
> +
> +for_each_cpu ( i, per_cpu(cpu_sibling_mask, cpu) )
> +{
> +if ( cpu == i )
> +break;
> +c[cpu].cpu_thread_id++;
No. This wants doing alongside setting of the other similar fields,
i.e. in (at least) detect_extended_topology() and detect_ht(). It
is the hardware which tells us what the thread ID is.
>>> I wasn't able to find the related information for AMD cpus. In case it
>>> is in the specs it is hidden very well.
>> What was used for compute units in Fam16 and earlier is used for
>> hyperthreads in Fam17 (and going forward, from what iirc Brian
>> has said).
> And what about hyperthreads in Fam16 and earlier? Or are "compute units"
> just another name for the threads and I can rename that field?
Fam 15/16 "Compute Units" are complicated.
The have a shared L1 I$, fetch and branch prediction, separate integer
pipelines, but a shared FPU pipeline.
Half of the pipeline looks very much like threads, and half looks like
separate cores.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] add cpu_thread_id to struct cpuinfo_x86
>>> On 03.09.18 at 16:52, wrote:
> On 03/09/18 16:47, Jan Beulich wrote:
> On 03.09.18 at 15:53, wrote:
>>> On 03/09/18 15:46, Jan Beulich wrote:
>>> On 31.08.18 at 18:22, wrote:
> Add the thread-id to the cpu config data and an accessor macro
> cpu_to_thread().
>
> Signed-off-by: Juergen Gross
> ---
> xen/arch/x86/cpu/common.c | 1 +
> xen/arch/x86/smpboot.c | 10 ++
> xen/include/asm-arm/processor.h | 1 +
> xen/include/asm-x86/processor.h | 2 ++
> xen/include/public/sysctl.h | 1 +
> 5 files changed, 15 insertions(+)
>
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index 057859ab14..f626a6a510 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -434,6 +434,7 @@ void identify_cpu(struct cpuinfo_x86 *c)
> c->phys_proc_id = XEN_INVALID_SOCKET_ID;
> c->cpu_core_id = XEN_INVALID_CORE_ID;
> c->compute_unit_id = INVALID_CUID;
> + c->cpu_thread_id = XEN_INVALID_THREAD_ID;
> memset(>x86_capability, 0, sizeof c->x86_capability);
>
> generic_identify(c);
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 7e76cc3d68..2c6a40c543 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -247,6 +247,8 @@ static void set_cpu_sibling_map(unsigned int cpu)
> cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
> cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>
> +c[cpu].cpu_thread_id = 0;
> +
> if ( c[cpu].x86_num_siblings > 1 )
> {
> for_each_cpu ( i, _sibling_setup_map )
> @@ -270,6 +272,14 @@ static void set_cpu_sibling_map(unsigned int cpu)
> "CPU%u: unclear relationship with CPU%u\n",
> cpu, i);
> }
> +
> +for_each_cpu ( i, per_cpu(cpu_sibling_mask, cpu) )
> +{
> +if ( cpu == i )
> +break;
> +c[cpu].cpu_thread_id++;
No. This wants doing alongside setting of the other similar fields,
i.e. in (at least) detect_extended_topology() and detect_ht(). It
is the hardware which tells us what the thread ID is.
>>>
>>> I wasn't able to find the related information for AMD cpus. In case it
>>> is in the specs it is hidden very well.
>>
>> What was used for compute units in Fam16 and earlier is used for
>> hyperthreads in Fam17 (and going forward, from what iirc Brian
>> has said).
>
> And what about hyperthreads in Fam16 and earlier? Or are "compute units"
> just another name for the threads and I can rename that field?
When there are compute units, there are no threads. But the difference
is more than just the names, so folding the fields is not a good idea imo.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 127212: tolerable all pass - PUSHED
flight 127212 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/127212/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 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 16bbf8e7b39b50457bb2f6547f166bd54d50e4cd baseline version: xen f04955e18502035121776f6e09d83ae5a36c773c Last test of basis 126996 2018-08-30 15:01:02 Z3 days Failing since127042 2018-08-31 12:00:37 Z3 days 29 attempts Testing same since 127212 2018-09-03 13:00:29 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Christian Lindig Daniel De Graaf Jan Beulich Julien Grall Kevin Tian Razvan Cojocaru Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git f04955e185..16bbf8e7b3 16bbf8e7b39b50457bb2f6547f166bd54d50e4cd -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Xen Dom0 boot failure on platform that supports ARM GICv4
Hi,
I am trying to boot xen(stable-4.11) on one of our ARM64 boards which
has support for GICv4.
But dom0(kernel 4.18) boot fails with the below trap,
XEN) done.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 304kB init memory.
(XEN) traps.c:2007:d0v0 HSR=0x9384 pc=0x0841af04
gva=0x0b10ffe8 gpa=0x004000aa10ffe8
After a bit of debugging, it looks like, the GICR size used in
vgic_v3_domain_init()
is GICv4 GICR size(256K) and this upsets the first_cpu calculations.
Since dom0 gicv3 is also an emulated one, I think the size should be
restricted to use the GICv3 GICR size(128K). I have made the below
changes and is able to boot dom0 now.
But not sure, this is the right approach to fix the issue. Please let me
know your thoughts.
Thanks,
Shameer
>8-
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b2ed0f8..bf028cc 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1783,7 +1783,8 @@ static int __init gicv3_init(void)
reg = readl_relaxed(GICD + GICD_TYPER);
intid_bits = GICD_TYPE_ID_BITS(reg);
-vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
intid_bits);
+vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
+intid_bits, gic_dist_supports_dvis());
gicv3_init_v2();
spin_lock_init();
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4b42739..0f53d88 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -59,18 +59,21 @@ static struct {
unsigned int nr_rdist_regions;
const struct rdist_region *regions;
unsigned int intid_bits; /* Number of interrupt ID bits */
+bool dvis;
} vgic_v3_hw;
void vgic_v3_setup_hw(paddr_t dbase,
unsigned int nr_rdist_regions,
const struct rdist_region *regions,
- unsigned int intid_bits)
+ unsigned int intid_bits,
+ bool dvis)
{
vgic_v3_hw.enabled = true;
vgic_v3_hw.dbase = dbase;
vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
vgic_v3_hw.regions = regions;
vgic_v3_hw.intid_bits = intid_bits;
+vgic_v3_hw.dvis = dvis;
}
static struct vcpu *vgic_v3_irouter_to_vcpu(struct domain *d, uint64_t irouter)
@@ -1673,6 +1676,9 @@ static int vgic_v3_domain_init(struct domain *d)
{
paddr_t size = vgic_v3_hw.regions[i].size;
+if (vgic_v3_hw.dvis && (size == GICV4_GICR_SIZE))
+ size = GICV3_GICR_SIZE;
+
d->arch.vgic.rdist_regions[i].base = vgic_v3_hw.regions[i].base;
d->arch.vgic.rdist_regions[i].size = size;
@@ -1680,6 +1686,7 @@ static int vgic_v3_domain_init(struct domain *d)
d->arch.vgic.rdist_regions[i].first_cpu = first_cpu;
first_cpu += size / GICV3_GICR_SIZE;
+
}
d->arch.vgic.intid_bits = vgic_v3_hw.intid_bits;
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index a35449b..dabd5f6 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -979,7 +979,8 @@ unsigned int vgic_max_vcpus(const struct domain *d)
void vgic_v3_setup_hw(paddr_t dbase,
unsigned int nr_rdist_regions,
const struct rdist_region *regions,
- unsigned int intid_bits)
+ unsigned int intid_bits,
+ bool dvis)
{
panic("New VGIC implementation does not yet support GICv3.");
}
diff --git a/xen/include/asm-arm/gic_v3_defs.h
b/xen/include/asm-arm/gic_v3_defs.h
index 10a2aee..de1facf 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -73,6 +73,8 @@
/* Two pages for the RD_base and SGI_base register frame. */
#define GICV3_GICR_SIZE (2 * SZ_64K)
+#define GICV4_GICR_SIZE (4 * SZ_64K)
+
#define GICR_CTLR(0x)
#define GICR_IIDR(0x0004)
#define GICR_TYPER (0x0008)
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 2a58ea3..3890ad8 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -364,7 +364,8 @@ struct rdist_region;
void vgic_v3_setup_hw(paddr_t dbase,
unsigned int nr_rdist_regions,
const struct rdist_region *regions,
- unsigned int intid_bits);
+ unsigned int intid_bits,
+ bool dvis);
#endif
#endif /* __ASM_ARM_VGIC_H__ */
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] SMT/Hyperthreading detection not always correct
On 09/03/2018 03:35 PM, Jan Beulich wrote: On 03.09.18 at 15:24, wrote: >> (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x20] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x30] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x24] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x14] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x1c] lapic_id[0x34] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x22] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x12] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x1a] lapic_id[0x32] enabled) >> (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x26] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x16] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x1e] lapic_id[0x36] disabled) > > These look to be all the primary threads, the last few disabled due > to being absent. > >> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x21] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x11] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x19] lapic_id[0x31] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x15] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x1d] lapic_id[0x35] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x23] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x13] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x1b] lapic_id[0x33] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x27] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x17] disabled) >> (XEN) ACPI: LAPIC (acpi_id[0x1f] lapic_id[0x37] disabled) > > And these are all the secondary threads afaict, which are all > disabled. I'm unconvinced we can assume a system is not using > hyperthreading simply based upon their MADT entries showing all > of them as disabled - what if a HT-enabled CPU was later > hotplugged? > > I would have hoped that the topology related CPUID output > would change when HT is (properly) disabled by the BIOS. > > For the moment I can't see a way around you specifying "smt=0" > on systems like this one. The actual reason why I started the conversation about it was that for a regular end user, the message telling the user that he has "hardware with SMT/Hyperthreading enabled" is a confusing thing if you just made sure that you have it disabled in the settings. So, alternatively, instead of a technical solution, the warning could be changed to something like "Booted on L1TF-vulnerable hardware and unable to properly detect if SMT/Hyperthreading is enabled or disabled Please choose explicit smt setting blah to make sure that it behaves how you want." As a user, that's less confusing, it just tells me that Xen likes me to make explicit what I want. Hans ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] add cpu_thread_id to struct cpuinfo_x86
On 03/09/18 16:47, Jan Beulich wrote:
On 03.09.18 at 15:53, wrote:
>> On 03/09/18 15:46, Jan Beulich wrote:
>> On 31.08.18 at 18:22, wrote:
Add the thread-id to the cpu config data and an accessor macro
cpu_to_thread().
Signed-off-by: Juergen Gross
---
xen/arch/x86/cpu/common.c | 1 +
xen/arch/x86/smpboot.c | 10 ++
xen/include/asm-arm/processor.h | 1 +
xen/include/asm-x86/processor.h | 2 ++
xen/include/public/sysctl.h | 1 +
5 files changed, 15 insertions(+)
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 057859ab14..f626a6a510 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -434,6 +434,7 @@ void identify_cpu(struct cpuinfo_x86 *c)
c->phys_proc_id = XEN_INVALID_SOCKET_ID;
c->cpu_core_id = XEN_INVALID_CORE_ID;
c->compute_unit_id = INVALID_CUID;
+ c->cpu_thread_id = XEN_INVALID_THREAD_ID;
memset(>x86_capability, 0, sizeof c->x86_capability);
generic_identify(c);
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 7e76cc3d68..2c6a40c543 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -247,6 +247,8 @@ static void set_cpu_sibling_map(unsigned int cpu)
cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
+c[cpu].cpu_thread_id = 0;
+
if ( c[cpu].x86_num_siblings > 1 )
{
for_each_cpu ( i, _sibling_setup_map )
@@ -270,6 +272,14 @@ static void set_cpu_sibling_map(unsigned int cpu)
"CPU%u: unclear relationship with CPU%u\n",
cpu, i);
}
+
+for_each_cpu ( i, per_cpu(cpu_sibling_mask, cpu) )
+{
+if ( cpu == i )
+break;
+c[cpu].cpu_thread_id++;
>>>
>>> No. This wants doing alongside setting of the other similar fields,
>>> i.e. in (at least) detect_extended_topology() and detect_ht(). It
>>> is the hardware which tells us what the thread ID is.
>>
>> I wasn't able to find the related information for AMD cpus. In case it
>> is in the specs it is hidden very well.
>
> What was used for compute units in Fam16 and earlier is used for
> hyperthreads in Fam17 (and going forward, from what iirc Brian
> has said).
And what about hyperthreads in Fam16 and earlier? Or are "compute units"
just another name for the threads and I can rename that field?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] hvmloader: fix build with LLVM Linker
>>> On 03.09.18 at 16:19, wrote:
> On Mon, Aug 27, 2018 at 03:50:39AM -0600, Jan Beulich wrote:
>> >>> On 24.08.18 at 11:58, wrote:
>> > --- /dev/null
>> > +++ b/tools/firmware/hvmloader/hvmloader.lds
>> > @@ -0,0 +1,13 @@
>> > +SECTIONS
>> > +{
>> > + . = 0x10;
>> > + /*
>> > + * NB: there's no need to use the AT keyword in order to set the LMA, by
>> > + * default the linker will use VMA = LMA unless specified otherwise.
>> > + */
>> > + .text : { *(.text) }
>> > + .rodata : { *(.rodata) }
>> > + .data : { *(.data) }
>> > + .bss : { *(.bss) }
>> > + _end = .;
>> > +}
>>
>> Is this really sufficient? Iirc the compiler could create quite a few
>> more variants of the sections named above, like .rodata.str* or
>> .text.cold. Hence at the very least I'd expect . on the
>> right sides above to be accompanied by ..* .
>
> Right, ATM the compiler I'm using doesn't generate any of those, but
> you are correct that this could be the case.
>
> Do you have a preference for adding ..* instead of just using
> a single .*?
Yes, I think we shouldn't match more aggressively than we have to.
.text.* etc are well known forms, and while .text1 etc may also be,
I wouldn't want to match more exotic ones like .textual.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM
>>> On 03.09.18 at 16:27, wrote:
> On Thu, Aug 30, 2018 at 02:35:37AM -0600, Jan Beulich wrote:
>> >>> On 30.08.18 at 09:42, wrote:
>> > On Tue, Aug 28, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
>> >> >>> On 26.08.18 at 14:19, wrote:
>> >> > --- a/xen/arch/x86/mm/paging.c
>> >> > +++ b/xen/arch/x86/mm/paging.c
>> >> > @@ -919,6 +919,7 @@ const struct paging_mode *paging_get_mode(struct
>> >> > vcpu
>> > *v)
>> >> > return paging_get_nestedmode(v);
>> >> > }
>> >> >
>> >> > +#ifdef CONFIG_HVM
>> >> > void paging_update_nestedmode(struct vcpu *v)
>> >> > {
>> >> > ASSERT(nestedhvm_enabled(v->domain));
>> >> > @@ -930,6 +931,7 @@ void paging_update_nestedmode(struct vcpu *v)
>> >> > v->arch.paging.nestedmode = NULL;
>> >> > hvm_asid_flush_vcpu(v);
>> >> > }
>> >> > +#endif
>> >>
>> >> Just a consideration (no objection): Would it be worthwhile to
>> >> introduce CONFIG_NESTED_HVM at the same time (for now hard
>> >> coded to Y, and of course depending on HVM) to avoid having to
>> >> touch all such places a second time later on?
>> >
>> > If we plan to make nested hvm configurable in the future, that would be
>> > a worthwhile thing to do; otherwise it is just another concept that
>> > users need to care about, which creates some mental burden.
>>
>> Andrew, do you have any opinion / preference either way?
>
> I discussed this with Andrew on IRC and came to the conclusion it is not
> worth it to introduce CONFIG_NESTED_HVM, because:
>
> 1. Nested virt will become commonplace for Xen.
> 2. Trying to split nested parts from non-nested parts will be massively
>complicated.
Okay then.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 1/2] add cpu_thread_id to struct cpuinfo_x86
>>> On 03.09.18 at 15:53, wrote:
> On 03/09/18 15:46, Jan Beulich wrote:
> On 31.08.18 at 18:22, wrote:
>>> Add the thread-id to the cpu config data and an accessor macro
>>> cpu_to_thread().
>>>
>>> Signed-off-by: Juergen Gross
>>> ---
>>> xen/arch/x86/cpu/common.c | 1 +
>>> xen/arch/x86/smpboot.c | 10 ++
>>> xen/include/asm-arm/processor.h | 1 +
>>> xen/include/asm-x86/processor.h | 2 ++
>>> xen/include/public/sysctl.h | 1 +
>>> 5 files changed, 15 insertions(+)
>>>
>>> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
>>> index 057859ab14..f626a6a510 100644
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -434,6 +434,7 @@ void identify_cpu(struct cpuinfo_x86 *c)
>>> c->phys_proc_id = XEN_INVALID_SOCKET_ID;
>>> c->cpu_core_id = XEN_INVALID_CORE_ID;
>>> c->compute_unit_id = INVALID_CUID;
>>> + c->cpu_thread_id = XEN_INVALID_THREAD_ID;
>>> memset(>x86_capability, 0, sizeof c->x86_capability);
>>>
>>> generic_identify(c);
>>> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
>>> index 7e76cc3d68..2c6a40c543 100644
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -247,6 +247,8 @@ static void set_cpu_sibling_map(unsigned int cpu)
>>> cpumask_set_cpu(cpu, per_cpu(cpu_core_mask, cpu));
>>> cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
>>>
>>> +c[cpu].cpu_thread_id = 0;
>>> +
>>> if ( c[cpu].x86_num_siblings > 1 )
>>> {
>>> for_each_cpu ( i, _sibling_setup_map )
>>> @@ -270,6 +272,14 @@ static void set_cpu_sibling_map(unsigned int cpu)
>>> "CPU%u: unclear relationship with CPU%u\n",
>>> cpu, i);
>>> }
>>> +
>>> +for_each_cpu ( i, per_cpu(cpu_sibling_mask, cpu) )
>>> +{
>>> +if ( cpu == i )
>>> +break;
>>> +c[cpu].cpu_thread_id++;
>>
>> No. This wants doing alongside setting of the other similar fields,
>> i.e. in (at least) detect_extended_topology() and detect_ht(). It
>> is the hardware which tells us what the thread ID is.
>
> I wasn't able to find the related information for AMD cpus. In case it
> is in the specs it is hidden very well.
What was used for compute units in Fam16 and earlier is used for
hyperthreads in Fam17 (and going forward, from what iirc Brian
has said).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/5] xen/domain: Cleanup to the domain_create() error paths
This is the start of a large amount of cleanup work to eventually allow for
the removal of XEN_DOMCTL_max_cpus hypercall.
The work to do is:
1) Make the domain destruction path fully idempotent, and use instead of the
ad-hoc cleanup in each of the various create functions.
2) Do the same for the vcpu create/destroy path (which is in a far worse
mess).
The arch-specific ARM code is all idempotent, but the common and x86 code has
a long way to go.
With this done, we should be able to cleanly unwind from any failure at any
point during domain creation, including when moving the vcpu allocation loop
into domain_create().
Andrew Cooper (5):
xen/domain: Prepare data for is_{pv,hvm}_domain() as early as possible
xen/domain: Break __domain_destroy() out of domain_create() and
complete_domain_destroy()
xen/domain: Call lock_profile_deregister_struct() from common code
xen/domain: Fold xsm_free_security_domain() paths together
xen/domain: Make rangeset_domain_destroy() idempotent
xen/arch/x86/domain.c | 1 -
xen/common/domain.c | 62 +++
xen/common/rangeset.c | 3 +++
3 files changed, 41 insertions(+), 25 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/5] xen/domain: Prepare data for is_{pv, hvm}_domain() as early as possible
Given two subtle failures from getting this wrong before, and more cleanup on
the way, move the setting of d->guest_type as early as possible.
Note that despite moving the assignment of d->guest_type outside of the
is_idle_domain(d) check, it still behaves the same. Previously, system
domains had no direct assignment of d->guest_type and behaved as PV guests
because guest_type_pv has the value 0.
While tidying up the predicate, leave a comment refering to
is_system_domain(), and move the associated ASSERT() to be beside the
asignment.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/domain.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 256c59a..43ab926 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -272,8 +272,12 @@ struct domain *domain_create(domid_t domid,
if ( (d = alloc_domain_struct()) == NULL )
return ERR_PTR(-ENOMEM);
+/* Sort out our idea of is_system_domain(). */
d->domain_id = domid;
+/* Debug sanity. */
+ASSERT(is_system_domain(d) ? config == NULL : config != NULL);
+
/* Sort out our idea of is_control_domain(). */
d->is_privileged = is_priv;
@@ -289,8 +293,11 @@ struct domain *domain_create(domid_t domid,
hardware_domain = d;
}
-/* Debug sanity. */
-ASSERT(is_system_domain(d) ? config == NULL : config != NULL);
+/* Sort out our idea of is_{pv,hvm}_domain(). */
+if ( config && (config->flags & XEN_DOMCTL_CDF_hvm_guest) )
+d->guest_type = guest_type_hvm;
+else
+d->guest_type = guest_type_pv;
TRACE_1D(TRC_DOM0_DOM_ADD, d->domain_id);
@@ -331,11 +338,6 @@ struct domain *domain_create(domid_t domid,
if ( !is_idle_domain(d) )
{
-if ( config->flags & XEN_DOMCTL_CDF_hvm_guest )
-d->guest_type = guest_type_hvm;
-else
-d->guest_type = guest_type_pv;
-
if ( !is_hardware_domain(d) )
d->nr_pirqs = nr_static_irqs + extra_domU_irqs;
else
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/5] xen/domain: Fold xsm_free_security_domain() paths together
xsm_free_security_domain() is idempotent (both the dummy handler, and the
flask handler). Move it into the shared __domain_destroy() path, and drop the
INIT_xsm flag from domain_create()
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Daniel De Graaf
---
xen/common/domain.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 9f810d1..d1c1993 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -274,6 +274,8 @@ static void __domain_destroy(struct domain *d)
free_cpumask_var(d->dirty_cpumask);
+xsm_free_security_domain(d);
+
lock_profile_deregister_struct(LOCKPROF_TYPE_PERDOM, d);
free_domain_struct(d);
@@ -284,7 +286,7 @@ struct domain *domain_create(domid_t domid,
bool is_priv)
{
struct domain *d, **pd, *old_hwdom = NULL;
-enum { INIT_xsm = 1u<<0, INIT_watchdog = 1u<<1, INIT_rangeset = 1u<<2,
+enum { INIT_watchdog = 1u<<1, INIT_rangeset = 1u<<2,
INIT_evtchn = 1u<<3, INIT_gnttab = 1u<<4, INIT_arch = 1u<<5 };
int err, init_status = 0;
@@ -324,7 +326,6 @@ struct domain *domain_create(domid_t domid,
if ( (err = xsm_alloc_security_domain(d)) != 0 )
goto fail;
-init_status |= INIT_xsm;
atomic_set(>refcnt, 1);
spin_lock_init_prof(d, domain_lock);
@@ -478,8 +479,6 @@ struct domain *domain_create(domid_t domid,
rangeset_domain_destroy(d);
if ( init_status & INIT_watchdog )
watchdog_domain_destroy(d);
-if ( init_status & INIT_xsm )
-xsm_free_security_domain(d);
__domain_destroy(d);
@@ -917,7 +916,6 @@ static void complete_domain_destroy(struct rcu_head *head)
radix_tree_destroy(>pirq_tree, free_pirq_struct);
-xsm_free_security_domain(d);
xfree(d->vcpu);
__domain_destroy(d);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/5] xen/domain: Break __domain_destroy() out of domain_create() and complete_domain_destroy()
This is the first step in making the destroy path idepotent, and using it in
place of the ad-hoc cleanup paths in the create path.
To begin with, the trivial free operations are broken out. The rest of the
cleanup code will be moved as it is demonstrated (or made) to be idempotent.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/domain.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 43ab926..2253c2d 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -260,6 +260,23 @@ static int __init parse_extra_guest_irqs(const char *s)
}
custom_param("extra_guest_irqs", parse_extra_guest_irqs);
+/*
+ * Destroy a domain once all references to it have been dropped. Used either
+ * from the RCU path, or from the domain_create() error path before the domain
+ * is inserted into the domlist.
+ */
+static void __domain_destroy(struct domain *d)
+{
+BUG_ON(!d->is_dying);
+BUG_ON(atomic_read(>refcnt) != DOMAIN_DESTROYED);
+
+xfree(d->pbuf);
+
+free_cpumask_var(d->dirty_cpumask);
+
+free_domain_struct(d);
+}
+
struct domain *domain_create(domid_t domid,
struct xen_domctl_createdomain *config,
bool is_priv)
@@ -437,7 +454,6 @@ struct domain *domain_create(domid_t domid,
if ( hardware_domain == d )
hardware_domain = old_hwdom;
atomic_set(>refcnt, DOMAIN_DESTROYED);
-xfree(d->pbuf);
sched_destroy_domain(d);
@@ -462,8 +478,9 @@ struct domain *domain_create(domid_t domid,
watchdog_domain_destroy(d);
if ( init_status & INIT_xsm )
xsm_free_security_domain(d);
-free_cpumask_var(d->dirty_cpumask);
-free_domain_struct(d);
+
+__domain_destroy(d);
+
return ERR_PTR(err);
}
@@ -881,8 +898,6 @@ static void complete_domain_destroy(struct rcu_head *head)
xfree(d->vm_event_share);
#endif
-xfree(d->pbuf);
-
for ( i = d->max_vcpus - 1; i >= 0; i-- )
if ( (v = d->vcpu[i]) != NULL )
{
@@ -901,9 +916,9 @@ static void complete_domain_destroy(struct rcu_head *head)
radix_tree_destroy(>pirq_tree, free_pirq_struct);
xsm_free_security_domain(d);
-free_cpumask_var(d->dirty_cpumask);
xfree(d->vcpu);
-free_domain_struct(d);
+
+__domain_destroy(d);
send_global_virq(VIRQ_DOM_EXC);
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5/5] xen/domain: Make rangeset_domain_destroy() idempotent
... and move it into the common __domain_destroy() path.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/domain.c | 9 +++--
xen/common/rangeset.c | 3 +++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index d1c1993..2f2f152 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -272,6 +272,8 @@ static void __domain_destroy(struct domain *d)
xfree(d->pbuf);
+rangeset_domain_destroy(d);
+
free_cpumask_var(d->dirty_cpumask);
xsm_free_security_domain(d);
@@ -286,7 +288,7 @@ struct domain *domain_create(domid_t domid,
bool is_priv)
{
struct domain *d, **pd, *old_hwdom = NULL;
-enum { INIT_watchdog = 1u<<1, INIT_rangeset = 1u<<2,
+enum { INIT_watchdog = 1u<<1,
INIT_evtchn = 1u<<3, INIT_gnttab = 1u<<4, INIT_arch = 1u<<5 };
int err, init_status = 0;
@@ -350,7 +352,6 @@ struct domain *domain_create(domid_t domid,
goto fail;
rangeset_domain_initialise(d);
-init_status |= INIT_rangeset;
/* DOMID_{XEN,IO,etc} (other than IDLE) are sufficiently constructed. */
if ( is_system_domain(d) && !is_idle_domain(d) )
@@ -475,8 +476,6 @@ struct domain *domain_create(domid_t domid,
evtchn_destroy_final(d);
radix_tree_destroy(>pirq_tree, free_pirq_struct);
}
-if ( init_status & INIT_rangeset )
-rangeset_domain_destroy(d);
if ( init_status & INIT_watchdog )
watchdog_domain_destroy(d);
@@ -882,8 +881,6 @@ static void complete_domain_destroy(struct rcu_head *head)
watchdog_domain_destroy(d);
-rangeset_domain_destroy(d);
-
sched_destroy_domain(d);
/* Free page used by xen oprofile buffer. */
diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 7788cdd..e3857ab 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -482,6 +482,9 @@ void rangeset_domain_destroy(
{
struct rangeset *r;
+if ( list_head_is_null(>rangesets) )
+return;
+
while ( !list_empty(>rangesets) )
{
r = list_entry(d->rangesets.next, struct rangeset, rangeset_list);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/5] xen/domain: Call lock_profile_deregister_struct() from common code
lock_profile_register_struct() is called from common code, but the matching
deregister was previously only called from x86 code.
The practical upshot of this when using CONFIG_LOCK_PROFILE, destroyed domains
on ARM (and in particular, the freed page behind struct domain) remain on the
lockprofile linked list, which will become corrupt when the page is reused.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
---
xen/arch/x86/domain.c | 1 -
xen/common/domain.c | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 688f7fb..cd1419e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -298,7 +298,6 @@ struct domain *alloc_domain_struct(void)
void free_domain_struct(struct domain *d)
{
-lock_profile_deregister_struct(LOCKPROF_TYPE_PERDOM, d);
free_xenheap_page(d);
}
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 2253c2d..9f810d1 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -274,6 +274,8 @@ static void __domain_destroy(struct domain *d)
free_cpumask_var(d->dirty_cpumask);
+lock_profile_deregister_struct(LOCKPROF_TYPE_PERDOM, d);
+
free_domain_struct(d);
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/2] tools/libxl: Switch Arm guest type to PVH
On Mon, Sep 03, 2018 at 12:15:16PM +0100, Julien Grall wrote: > On 03/09/18 12:09, Julien Grall wrote: > > > > > > On 23/08/18 08:58, Roger Pau Monné wrote: > > > On Wed, Aug 22, 2018 at 06:48:05PM +0100, Julien Grall wrote: > > > > > > > > > > > + > > > > > > + b_info->type = LIBXL_DOMAIN_TYPE_PVH; > > > > > > + > > > > > > + /* > > > > > > + * They only field in u.pv that matters on Arm are: > > > > > > kernel, cmdline, > > > > > > + * ramdisk. > > > > > > + */ > > > > > > + > > > > > > + if (!b_info->kernel && b_info->u.pv.kernel) > > > > > > + b_info->kernel = b_info->u.pv.kernel; > > > > > > + > > > > > > + if (!b_info->ramdisk && b_info->u.pv.ramdisk) > > > > > > + b_info->ramdisk = b_info->u.pv.ramdisk; > > > > > > + > > > > > > + if (!b_info->cmdline && b_info->u.pv.cmdline) > > > > > > + b_info->cmdline = b_info->u.pv.cmdline; > > > > > > + > > > > > > + /* Reset b_info->u.pvh to default values */ > > > > > > + memset(_info->u.pvh, 0, sizeof(b_info->u.pvh)); > > > > > > > > > > I'm afraid that's not correct. The default values for u.pvh are set > > > > > by libxl__domain_build_info_setdefault. > > > > > > > > I thought that this should be covered by the switch right after > > > > the call of > > > > libxl__arch_domain_build_info_setdefault. Did I miss anything? > > > > > > Oh right, libxl__arch_domain_build_info_setdefault is called by > > > libxl__domain_build_info_setdefault. > > > > > > > What I wanted to do here is resetting the union to 0 so you > > > > don't get data > > > > mangled by the pv fields. > > > > > > Another possible option I think would be to mark those fields as > > > deprecated in the IDL, and libxl__domain_build_info_copy_deprecated > > > will take care of copying them to the new place. In fact I think all > > > guest types should be using the top level kernel, ramdisk and cmdline > > > fields. > > > > I will have a look at it. > > > > > > > > I'm not specially comfortable with changing the guest type in the > > > middle of libxl__domain_build_info_setdefault, but I also don't have a > > > much better suggestion apart from using the deprecation helper. > > I forgot to answer to this bit. I don't think the deprecation helper will do > all the jobs. There are still PV specific parameters: slack_memkb, features, > e820_host. Those can be left inside the PV sub-struct and shouldn't be marked as deprecated. > Those are not necessary for Arm, if you don't zero them then you will not > initialize the PVH structure with default values. How do you suggest to > handle them? But I guess ARM doesn't use any of those fields (or else they should be moved to the pvh sub-struct anyway)? In which case allowing the user to set them in the first place seems like an error to me. Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v17 13/13] x86/domctl: Don't pause the whole domain if only getting vcpu state
On Fri, Aug 31, 2018 at 04:56:21PM +0300, Isaila Alexandru wrote: > On Mi, 2018-08-29 at 08:13 -0600, Jan Beulich wrote: > > > > > > > > > > > > > > > > > On 29.08.18 at 16:02, wrote: > > > On Mi, 2018-08-22 at 18:15 +0300, Isaila Alexandru wrote: > > > > > > > > On Mi, 2018-08-22 at 16:41 +0200, Roger Pau Monné wrote: > > > > > > > > > > If you look at vcpu_hvm in tools/libxc/xc_dom_x86.c it saves > > > > > the > > > > > full > > > > > domain context just to get the CPU and the MTRR state of > > > > > VCPU#0. Do > > > > > you think you could switch this code to use the newly > > > > > introduced > > > > > machinery to save a single instance of a specific type? > > > > Sure, I will add a tool patch at the end of the series > > > Is this urgent to be in this series? If not I will add a new patch > > > after it is all in. > > Considering the problems that there have been with this series, > > anything to help build confidence in things still working for all > > cases would help here, so I'm pretty glad Roger thought of this, > > and while I wouldn't make it as strong as "the series can't go > > in without this", I'd still much prefer if you too the time. > > I don't think it is possible to use getcontext_partial() in vcpu_hvm() > because of the need to have a header for xc_domain_hvm_setcontext() and > the only way to get it is by xc_domain_hvm_getcontext(). There is also > a comment there that states the same thing > "/* > * Get the full HVM context in order to have the header, it is not > * possible to get the header with getcontext_partial, and crafting > one > * from userspace is also not an option since cpuid is trapped and > * modified by Xen. > */ > " > I hope I understood the request correctly to start with and if not > please clarify. But I expect you also get such header when fetching the state of a single device, or else how do you use this new hypercall in conjunction with xc_domain_hvm_setcontext? Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 17/23] x86/mm: put paging_update_nestedmode under CONFIG_HVM
On Thu, Aug 30, 2018 at 02:35:37AM -0600, Jan Beulich wrote:
> >>> On 30.08.18 at 09:42, wrote:
> > On Tue, Aug 28, 2018 at 04:50:21AM -0600, Jan Beulich wrote:
> >> >>> On 26.08.18 at 14:19, wrote:
> >> > --- a/xen/arch/x86/mm/paging.c
> >> > +++ b/xen/arch/x86/mm/paging.c
> >> > @@ -919,6 +919,7 @@ const struct paging_mode *paging_get_mode(struct
> >> > vcpu
> > *v)
> >> > return paging_get_nestedmode(v);
> >> > }
> >> >
> >> > +#ifdef CONFIG_HVM
> >> > void paging_update_nestedmode(struct vcpu *v)
> >> > {
> >> > ASSERT(nestedhvm_enabled(v->domain));
> >> > @@ -930,6 +931,7 @@ void paging_update_nestedmode(struct vcpu *v)
> >> > v->arch.paging.nestedmode = NULL;
> >> > hvm_asid_flush_vcpu(v);
> >> > }
> >> > +#endif
> >>
> >> Just a consideration (no objection): Would it be worthwhile to
> >> introduce CONFIG_NESTED_HVM at the same time (for now hard
> >> coded to Y, and of course depending on HVM) to avoid having to
> >> touch all such places a second time later on?
> >
> > If we plan to make nested hvm configurable in the future, that would be
> > a worthwhile thing to do; otherwise it is just another concept that
> > users need to care about, which creates some mental burden.
>
> Andrew, do you have any opinion / preference either way?
I discussed this with Andrew on IRC and came to the conclusion it is not
worth it to introduce CONFIG_NESTED_HVM, because:
1. Nested virt will become commonplace for Xen.
2. Trying to split nested parts from non-nested parts will be massively
complicated.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] hvmloader: fix build with LLVM Linker
On Mon, Aug 27, 2018 at 03:50:39AM -0600, Jan Beulich wrote:
> >>> On 24.08.18 at 11:58, wrote:
> > --- /dev/null
> > +++ b/tools/firmware/hvmloader/hvmloader.lds
> > @@ -0,0 +1,13 @@
> > +SECTIONS
> > +{
> > + . = 0x10;
> > + /*
> > + * NB: there's no need to use the AT keyword in order to set the LMA, by
> > + * default the linker will use VMA = LMA unless specified otherwise.
> > + */
> > + .text : { *(.text) }
> > + .rodata : { *(.rodata) }
> > + .data : { *(.data) }
> > + .bss : { *(.bss) }
> > + _end = .;
> > +}
>
> Is this really sufficient? Iirc the compiler could create quite a few
> more variants of the sections named above, like .rodata.str* or
> .text.cold. Hence at the very least I'd expect . on the
> right sides above to be accompanied by ..* .
Right, ATM the compiler I'm using doesn't generate any of those, but
you are correct that this could be the case.
Do you have a preference for adding ..* instead of just using
a single .*?
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
