Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig
>>> On 07.03.17 at 18:48, wrote: > Here some concrete examples. The major bootloaders on ARM today are: > * UEFI > * U-boot > * GRUB > > I will leave UEFI aside as people will usually chainload to GRUB and > then boot whatever they want. > > In both GRUB and U-boot a user will be able to modify the command line > from the bootloader shell. Thanks. So I think the takeaway is that ARM doesn't strictly need the Dom0 part of the handling, but then again if this was common code it also shouldn't hurt. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 6/7] xen/mce: remove ASSERT's about mce_[u|d]handler_num in mce_action()
>>> On 08.03.17 at 02:58, wrote: > Those assertions as well as mce_[u|d]handlers[], mce_[u|d]handler_num > and mce_action() were intel only and lifted to the common code by c/s > 3a91769d6e1. However, MCE handling on AMD does not use mce_[u|d]handlers[] > before and after that commit, so assertions in mce_action() about their > size do not make sense for AMD. To be worse, they can crash the debug > build on AMD. Remove them to make the debug build work on AMD. > > Signed-off-by: Haozhong Zhang Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/emul: Avoid #UD when emulating v{, u}comis{s, d}
>>> On 08.03.17 at 00:32, wrote:
> v{,u}comis{s,d} have two operands, so require vex.reg set to ~0.
>
> Spotted by AFL
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
I'm sorry for the oversight.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig
>>> On 08.03.17 at 08:16, wrote: > 4. As for the different behavior between arm and x86 on handling the > dom0 options after " -- " in the > command line, I will left this difference as untouched, coz > whether to add this feature to arm or to remove > this feature from x86 is beyond the scope of this patch. Since you want to move the logic to common code, the result would likely end up better if there was no arch-dependent behavior. > But there's one thing that I'm not quite sure. Since currently there > isn't any cumulative options in > Xen, I just can't deal with them - Jan? Well, dealing with them simply means writing the config option help text accordingly (i.e. avoid explicitly ruling out that case). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 106534: tolerable FAIL - PUSHED
flight 106534 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/106534/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106513 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106513 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106513 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106513 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 106513 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 106513 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 106513 test-amd64-amd64-xl-rtds 9 debian-install fail like 106513 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass build-arm64 5 xen-buildfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen 4036e7c592905c2292cdeba8269e969959427237 baseline version: xen caf053fb545329e58ac891d197f96503e3121049 Last test of basis 106513 2017-03-07 05:59:24 Z1 days Testing same since 106534 2017-03-07 19:14:51 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich Roger Pau Monné jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64
[Xen-devel] [PATCH] MAINTAINERS: drop Christoph Egger
Other Amazon folks indicate he's not available as a maintainer anymore at this point in time. Maintenance of the MCE sub-component will fall back to the x86 maintainers. Signed-off-by: Jan Beulich --- a/MAINTAINERS +++ b/MAINTAINERS @@ -269,11 +269,6 @@ F: xen/include/asm-*/livepatch.h F: xen/include/xen/livepatch* F: xen/test/livepatch/* -MACHINE CHECK (MCA) & RAS -M: Christoph Egger -S: Supported -F: xen/arch/x86/cpu/mcheck/ - MINI-OS M: Samuel Thibault S: Supported MAINTAINERS: drop Christoph Egger Other Amazon folks indicate he's not available as a maintainer anymore at this point in time. Maintenance of the MCE sub-component will fall back to the x86 maintainers. Signed-off-by: Jan Beulich --- a/MAINTAINERS +++ b/MAINTAINERS @@ -269,11 +269,6 @@ F: xen/include/asm-*/livepatch.h F: xen/include/xen/livepatch* F: xen/test/livepatch/* -MACHINE CHECK (MCA) & RAS -M: Christoph Egger -S: Supported -F: xen/arch/x86/cpu/mcheck/ - MINI-OS M: Samuel Thibault S: Supported ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/altp2m: Added xc_altp2m_set_mem_access_multi()
For the default EPT view we have xc_set_mem_access_multi(), which
is able to set an array of pages to an array of access rights with
a single hypercall. However, this functionality was lacking for the
altp2m subsystem, which could only set page restrictions for one
page at a time. This patch addresses the gap.
Signed-off-by: Razvan Cojocaru
---
tools/libxc/include/xenctrl.h | 3 +++
tools/libxc/xc_altp2m.c | 41 +
xen/arch/x86/hvm/hvm.c | 30 +++---
xen/include/public/hvm/hvm_op.h | 28 +++-
4 files changed, 94 insertions(+), 8 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index a48981a..645b5bd 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1903,6 +1903,9 @@ int xc_altp2m_switch_to_view(xc_interface *handle,
domid_t domid,
int xc_altp2m_set_mem_access(xc_interface *handle, domid_t domid,
uint16_t view_id, xen_pfn_t gfn,
xenmem_access_t access);
+int xc_altp2m_set_mem_access_multi(xc_interface *handle, domid_t domid,
+ uint16_t view_id, uint8_t *access,
+ uint64_t *pages, uint32_t nr);
int xc_altp2m_change_gfn(xc_interface *handle, domid_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 0639632..f202ca1 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -188,6 +188,47 @@ int xc_altp2m_set_mem_access(xc_interface *handle, domid_t
domid,
return rc;
}
+int xc_altp2m_set_mem_access_multi(xc_interface *xch, domid_t domid,
+ uint16_t view_id, uint8_t *access,
+ uint64_t *pages, uint32_t nr)
+{
+int rc;
+
+DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+DECLARE_HYPERCALL_BOUNCE(access, nr, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+DECLARE_HYPERCALL_BOUNCE(pages, nr * sizeof(uint64_t),
+ XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+arg->cmd = HVMOP_altp2m_set_mem_access_multi;
+arg->domain = domid;
+arg->u.set_mem_access_multi.view = view_id;
+arg->u.set_mem_access_multi.nr = nr;
+
+if ( xc_hypercall_bounce_pre(xch, pages) ||
+ xc_hypercall_bounce_pre(xch, access) )
+{
+PERROR("Could not bounce memory for
HVMOP_altp2m_set_mem_access_multi");
+return -1;
+}
+
+set_xen_guest_handle(arg->u.set_mem_access_multi.pfn_list, pages);
+set_xen_guest_handle(arg->u.set_mem_access_multi.access_list, access);
+
+rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+ HYPERCALL_BUFFER_AS_ARG(arg));
+
+xc_hypercall_buffer_free(xch, arg);
+xc_hypercall_bounce_post(xch, access);
+xc_hypercall_bounce_post(xch, pages);
+
+return rc;
+}
+
int xc_altp2m_change_gfn(xc_interface *handle, domid_t domid,
uint16_t view_id, xen_pfn_t old_gfn,
xen_pfn_t new_gfn)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ccfae4f..cc9b207 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4394,11 +4394,13 @@ static int hvmop_get_param(
}
static int do_altp2m_op(
+unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
{
struct xen_hvm_altp2m_op a;
struct domain *d = NULL;
-int rc = 0;
+long rc = 0;
+unsigned long start_iter = cmd & ~MEMOP_CMD_MASK;
if ( !hvm_altp2m_supported() )
return -EOPNOTSUPP;
@@ -4419,6 +4421,7 @@ static int do_altp2m_op(
case HVMOP_altp2m_destroy_p2m:
case HVMOP_altp2m_switch_p2m:
case HVMOP_altp2m_set_mem_access:
+case HVMOP_altp2m_set_mem_access_multi:
case HVMOP_altp2m_change_gfn:
break;
default:
@@ -4535,6 +4538,25 @@ static int do_altp2m_op(
a.u.set_mem_access.view);
break;
+case HVMOP_altp2m_set_mem_access_multi:
+if ( a.u.set_mem_access_multi.pad )
+{
+rc = -EINVAL;
+break;
+}
+rc = p2m_set_mem_access_multi(d, a.u.set_mem_access_multi.pfn_list,
+ a.u.set_mem_access_multi.access_list,
+ a.u.set_mem_access_multi.nr, start_iter,
+ MEMOP_CMD_MASK,
+ a.u.set_mem_access_multi.view);
+if ( rc > 0 )
+{
+ASSERT(!(rc & MEMOP_CMD_MASK));
+rc = hypercall_create_continuation(__HYPERVISOR_hvm_op, "lh",
+
[Xen-devel] [xen-4.8-testing test] 106535: tolerable FAIL - PUSHED
flight 106535 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/106535/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail REGR. vs. 106095 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106095 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106095 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106095 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106095 test-amd64-amd64-xl-rtds 9 debian-install fail like 106095 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64 5 xen-buildfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen 2e68fda962226d4de916d5ceab9d9d6037d94d45 baseline version: xen 9967251965a4cea19e6f69f7c5472174c4c5b971 Last test of basis 106095 2017-02-24 21:47:16 Z 11 days Testing same since 106535 2017-03-07 19:40:21 Z0 days1 attempts People who touched revisions under test: Edgar E. Iglesias Stefano Stabellini jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass
[Xen-devel] [distros-debian-squeeze test] 68643: tolerable trouble: broken/fail/pass
flight 68643 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68643/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 68599 test-amd64-i386-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 68599 test-amd64-i386-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 68599 test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 68599 Tests which did not succeed, but are not blocking: build-arm64-pvops 2 hosts-allocate broken never pass build-arm64 2 hosts-allocate broken never pass build-arm64 3 capture-logs broken never pass build-arm64-pvops 3 capture-logs broken never pass baseline version: flight 68599 jobs: build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-pvopspass build-arm64-pvopsbroken build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-squeeze-netboot-pygrubfail test-amd64-i386-amd64-squeeze-netboot-pygrub fail test-amd64-amd64-i386-squeeze-netboot-pygrub fail test-amd64-i386-i386-squeeze-netboot-pygrub fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t
> On Mon, Mar 06, 2017 at 04:20:57PM +0200, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > > > > Signed-off-by: Elena Reshetova > > Signed-off-by: Hans Liljestrand > > Signed-off-by: Kees Cook > > Signed-off-by: David Windsor > > --- > > drivers/md/raid5-cache.c | 8 +++--- > > drivers/md/raid5.c | 66 > > > > drivers/md/raid5.h | 3 ++- > > 3 files changed, 39 insertions(+), 38 deletions(-) > > > > diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c > > index 3f307be..6c05e12 100644 > > --- a/drivers/md/raid5-cache.c > > +++ b/drivers/md/raid5-cache.c > > snip > >sh->check_state, sh->reconstruct_state); > > > > analyse_stripe(sh, &s); > > @@ -4924,7 +4924,7 @@ static void activate_bit_delay(struct r5conf *conf, > > struct stripe_head *sh = list_entry(head.next, struct > stripe_head, lru); > > int hash; > > list_del_init(&sh->lru); > > - atomic_inc(&sh->count); > > + refcount_inc(&sh->count); > > hash = sh->hash_lock_index; > > __release_stripe(conf, sh, > &temp_inactive_list[hash]); > > } > > @@ -5240,7 +5240,7 @@ static struct stripe_head > > *__get_priority_stripe(struct > r5conf *conf, int group) > > sh->group = NULL; > > } > > list_del_init(&sh->lru); > > - BUG_ON(atomic_inc_return(&sh->count) != 1); > > + BUG_ON(refcount_inc_not_zero(&sh->count)); > > This changes the behavior. refcount_inc_not_zero doesn't inc if original > value is 0 Hm.. So, you want to inc here in any case and BUG if the end result differs from 1. So essentially you want to only increment here from zero to one under normal conditions... This is a challenge for refcount_t and against the design. Is it ok just to maybe do this here: - BUG_ON(atomic_inc_return(&sh->count) != 1); + BUG_ON(refcount_read(&sh->count) != 0); + refcount_set((&sh->count, 1); Do we have an issue with locking in this case? Or maybe it is then better to leave this one to be atomic_t without protection since it isn't a real refcounter as it turns out. Best Regards, Elena. > > Thanks, > Shaohua ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 5/5] xen: use libxendevicemodel when available
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 07 March 2017 19:14
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano
> Stabellini
> Subject: Re: [PATCH v4 5/5] xen: use libxendevicemodel when available
>
> On Tue, 7 Mar 2017, Paul Durrant wrote:
> > This patch modifies the wrapper functions in xen_common.h to use the
> > new xendevicemodel interface if it is available along with compatibility
> > code to use the old libxenctrl interface if it is not.
> >
> > Signed-off-by: Paul Durrant
> > Reviewed-by: Anthony Perard
>
> Reviewed-by: Stefano Stabellini
>
Great. Thanks, and thanks for finding the compat issues.
> However, QEMU is in soft-freeze, so I'll wait until the merge window
> open again before sending the pull request.
>
Ok.
Cheers,
Paul
>
> > Cc: Stefano Stabellini
> >
> > v4:
> > - Fix typo causing build failures on < 490
> > - Fix building on < 450
> > - Build-tested against 4.2.5 and 4.8.0
> >
> > v3:
> > - Switch from macros to static inlines.
> >
> > v2:
> > - Add a compat define for xenforeignmemory_close() since this is now
> > used.
> > ---
> > include/hw/xen/xen_common.h | 203
> +---
> > xen-common.c| 8 ++
> > 2 files changed, 178 insertions(+), 33 deletions(-)
> >
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 31cf25f..274accc 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -9,6 +9,7 @@
> > #undef XC_WANT_COMPAT_EVTCHN_API
> > #undef XC_WANT_COMPAT_GNTTAB_API
> > #undef XC_WANT_COMPAT_MAP_FOREIGN_API
> > +#undef XC_WANT_COMPAT_DEVICEMODEL_API
> >
> > #include
> > #include
> > @@ -26,48 +27,183 @@ extern xc_interface *xen_xc;
> > * We don't support Xen prior to 4.2.0.
> > */
> >
> > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490
> > +
> > +typedef xc_interface xendevicemodel_handle;
> > +
> > +static inline xendevicemodel_handle *xendevicemodel_open(
> > +struct xentoollog_logger *logger, unsigned int open_flags)
> > +{
> > +return xen_xc;
> > +}
> > +
> > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450
> > +
> > +static inline int xendevicemodel_create_ioreq_server(
> > +xendevicemodel_handle *dmod, domid_t domid, int handle_bufioreq,
> > +ioservid_t *id)
> > +{
> > +return xc_hvm_create_ioreq_server(dmod, domid, handle_bufioreq,
> > + id);
> > +}
> > +
> > +static inline int xendevicemodel_get_ioreq_server_info(
> > +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
> > +xen_pfn_t *ioreq_pfn, xen_pfn_t *bufioreq_pfn,
> > +evtchn_port_t *bufioreq_port)
> > +{
> > +return xc_hvm_get_ioreq_server_info(dmod, domid, id, ioreq_pfn,
> > +bufioreq_pfn, bufioreq_port);
> > +}
> > +
> > +static inline int xendevicemodel_map_io_range_to_ioreq_server(
> > +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int
> is_mmio,
> > +uint64_t start, uint64_t end)
> > +{
> > +return xc_hvm_map_io_range_to_ioreq_server(dmod, domid, id,
> is_mmio,
> > + start, end);
> > +}
> > +
> > +static inline int xendevicemodel_unmap_io_range_from_ioreq_server(
> > +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int
> is_mmio,
> > +uint64_t start, uint64_t end)
> > +{
> > +return xc_hvm_unmap_io_range_from_ioreq_server(dmod, domid, id,
> is_mmio,
> > + start, end);
> > +}
> > +
> > +static inline int xendevicemodel_map_pcidev_to_ioreq_server(
> > +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
> > +uint16_t segment, uint8_t bus, uint8_t device, uint8_t function)
> > +{
> > +return xc_hvm_map_pcidev_to_ioreq_server(dmod, domid, id,
> segment,
> > + bus, device, function);
> > +}
> > +
> > +static inline int xendevicemodel_unmap_pcidev_from_ioreq_server(
> > +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
> > +uint16_t segment, uint8_t bus, uint8_t device, uint8_t function)
> > +{
> > +return xc_hvm_unmap_pcidev_from_ioreq_server(dmod, domid, id,
> segment,
> > + bus, device, function);
> > +}
> > +
> > +static inline int xendevicemodel_destroy_ioreq_server(
> > +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id)
> > +{
> > +return xc_hvm_destroy_ioreq_server(dmod, domid, id);
> > +}
> > +
> > +static inline int xendevicemodel_set_ioreq_server_state(
> > +xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int
> enabled)
> > +{
> > +return xc_hvm_set_ioreq_server_state(dmod, domid, id, enabled);
> > +}
> > +
> > +#endif /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450 */
> > +
> > +static inline int xendevicemodel_set_pci_intx_level(
> > +xendevi
Re: [Xen-devel] [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t
> On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
>
> Looks good. Let me know how do you want to route the patch to upstream.
Greg, you previously mentioned that driver's conversions can go via your tree.
Does this still apply?
Or should I be asking maintainers to merge these patches via their trees?
I am not sure about the correct (and easier for everyone) way, please suggest.
Best Regards,
Elena.
>
> > Signed-off-by: Elena Reshetova
> > Signed-off-by: Hans Liljestrand
> > Signed-off-by: Kees Cook
> > Signed-off-by: David Windsor
> > ---
> > drivers/md/md.c | 6 +++---
> > drivers/md/md.h | 3 ++-
> > 2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/md/md.c b/drivers/md/md.c
> > index 985374f..94c8ebf 100644
> > --- a/drivers/md/md.c
> > +++ b/drivers/md/md.c
> > @@ -449,7 +449,7 @@ EXPORT_SYMBOL(md_unplug);
> >
> > static inline struct mddev *mddev_get(struct mddev *mddev)
> > {
> > - atomic_inc(&mddev->active);
> > + refcount_inc(&mddev->active);
> > return mddev;
> > }
> >
> > @@ -459,7 +459,7 @@ static void mddev_put(struct mddev *mddev)
> > {
> > struct bio_set *bs = NULL;
> >
> > - if (!atomic_dec_and_lock(&mddev->active, &all_mddevs_lock))
> > + if (!refcount_dec_and_lock(&mddev->active, &all_mddevs_lock))
> > return;
> > if (!mddev->raid_disks && list_empty(&mddev->disks) &&
> > mddev->ctime == 0 && !mddev->hold_active) {
> > @@ -495,7 +495,7 @@ void mddev_init(struct mddev *mddev)
> > INIT_LIST_HEAD(&mddev->all_mddevs);
> > setup_timer(&mddev->safemode_timer, md_safemode_timeout,
> > (unsigned long) mddev);
> > - atomic_set(&mddev->active, 1);
> > + refcount_set(&mddev->active, 1);
> > atomic_set(&mddev->openers, 0);
> > atomic_set(&mddev->active_io, 0);
> > spin_lock_init(&mddev->lock);
> > diff --git a/drivers/md/md.h b/drivers/md/md.h
> > index b8859cb..4811663 100644
> > --- a/drivers/md/md.h
> > +++ b/drivers/md/md.h
> > @@ -22,6 +22,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -360,7 +361,7 @@ struct mddev {
> > */
> > struct mutexopen_mutex;
> > struct mutexreconfig_mutex;
> > - atomic_tactive;
> /* general refcount */
> > + refcount_t active;
> /* general refcount */
> > atomic_topeners;/*
> number of active opens */
> >
> > int
> changed;/* True if we might need to
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t
On Wed, Mar 08, 2017 at 09:42:09AM +, Reshetova, Elena wrote: > > On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote: > > > refcount_t type and corresponding API should be > > > used instead of atomic_t when the variable is used as > > > a reference counter. This allows to avoid accidental > > > refcounter overflows that might lead to use-after-free > > > situations. > > > > Looks good. Let me know how do you want to route the patch to upstream. > > Greg, you previously mentioned that driver's conversions can go via your > tree. Does this still apply? > Or should I be asking maintainers to merge these patches via their trees? You should ask them to take them through their trees, if they have them. I'll be glad to scoop up all of the remaining ones that get missed, or for subsystems that do not have trees. thanks, greg k-h ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: drop Christoph Egger
On 08/03/17 08:45, Jan Beulich wrote: > Other Amazon folks indicate he's not available as a maintainer anymore > at this point in time. Maintenance of the MCE sub-component will fall > back to the x86 maintainers. > > Signed-off-by: Jan Beulich Acked-by: Andrew Cooper For now, I am happy for this to fall under general x86 unless someone suitable re-volunteers. > > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -269,11 +269,6 @@ F: xen/include/asm-*/livepatch.h > F: xen/include/xen/livepatch* > F: xen/test/livepatch/* > > -MACHINE CHECK (MCA) & RAS > -M: Christoph Egger > -S: Supported > -F: xen/arch/x86/cpu/mcheck/ > - > MINI-OS > M: Samuel Thibault > S: Supported > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: drop Christoph Egger
On 08/03/17 10:35, Andrew Cooper wrote: > On 08/03/17 08:45, Jan Beulich wrote: >> Other Amazon folks indicate he's not available as a maintainer anymore >> at this point in time. Maintenance of the MCE sub-component will fall >> back to the x86 maintainers. >> >> Signed-off-by: Jan Beulich > > Acked-by: Andrew Cooper > > For now, I am happy for this to fall under general x86 unless someone > suitable re-volunteers. It would probably be polite to wait at least a few days for Christoph himself to respond before committing this patch. (Though I'd say it would be OK to commit any patches that would otherwise need his Ack, if they've already been waiting more than a week.) -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: drop Christoph Egger
On 08.03.17 09:45, Jan Beulich wrote: > Other Amazon folks indicate he's not available as a maintainer anymore > at this point in time. Maintenance of the MCE sub-component will fall > back to the x86 maintainers. > > Signed-off-by: Jan Beulich Acked-by: Christoph Egger > > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -269,11 +269,6 @@ F: xen/include/asm-*/livepatch.h > F: xen/include/xen/livepatch* > F: xen/test/livepatch/* > > -MACHINE CHECK (MCA) & RAS > -M: Christoph Egger > -S: Supported > -F: xen/arch/x86/cpu/mcheck/ > - > MINI-OS > M: Samuel Thibault > S: Supported > > > Amazon Development Center Germany GmbH Berlin - Dresden - Aachen main office: Krausenstr. 38, 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-coverity test] 106549: all pass - PUSHED
flight 106549 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106549/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 4361e80d228655b100bae5d19b489b39d20aa68d
baseline version:
xen 6d55c0c316357a412526b9dccd45d3c3abb75227
Last test of basis 106475 2017-03-05 09:18:47 Z3 days
Testing same since 106549 2017-03-08 09:20:26 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Edgar E. Iglesias
Jan Beulich
Paul Durrant
Razvan Cojocaru
Roger Pau Monné
Stefano Stabellini
Tamas K Lengyel
jobs:
coverity-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-coverity
+ revision=4361e80d228655b100bae5d19b489b39d20aa68d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push
xen-unstable-coverity 4361e80d228655b100bae5d19b489b39d20aa68d
+ branch=xen-unstable-coverity
+ revision=4361e80d228655b100bae5d19b489b39d20aa68d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.8-testing
+ '[' x4361e80d228655b100bae5d19b489b39d20aa68d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable-c
Re: [Xen-devel] [PATCH 1/7] xen: import new ring macros in ring.h
Hi Stefano, On 08/03/17 00:12, Stefano Stabellini wrote: On Tue, 7 Mar 2017, Julien Grall wrote: Hi Stefano, On 03/06/2017 08:01 PM, Stefano Stabellini wrote: Sync the ring.h file with upstream Xen, to introduce the new ring macros. They will be used by the Xen transport for 9pfs. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com CC: boris.ostrov...@oracle.com CC: jgr...@suse.com --- NB: The new macros have not been committed to Xen yet. Do not apply this patch until they do. --- --- include/xen/interface/io/ring.h | 131 1 file changed, 131 insertions(+) diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h index 21f4fbd..e16aa92 100644 --- a/include/xen/interface/io/ring.h +++ b/include/xen/interface/io/ring.h [...] +#define XEN_FLEX_RING_SIZE(order) \ +(1UL << (order + PAGE_SHIFT - 1)) This will need to be XEN_PAGE_SHIFT in order to works with 64K kernel. Good point! I had it right at the beginning but I lost the change in one of the updates from xen.git. It is probably worth to consider introducing XEN_PAGE_SIZE in the hypervisor code because we are likely to miss the change when the headers will be re-sync in the future. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/emul: Avoid #UD in SIMD stubs
v{,u}comis{s,d}, and vcvt{,t}s{s,d}2si are two-operand instructions, while
vzero{all,upper} take no operands, so require vex.reg set to ~0 to avoid #UD.
Spotted while fuzzing with AFL
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/x86_emulate/x86_emulate.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
b/xen/arch/x86/x86_emulate/x86_emulate.c
index e09975c..8134e76 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -5620,7 +5620,7 @@ x86_emulate(
{
if ( ctxt->vendor == X86_VENDOR_AMD )
vex.l = 0;
-generate_exception_if(vex.l, EXC_UD);
+generate_exception_if(vex.l || vex.reg != 0xf, EXC_UD);
host_and_vcpu_must_have(avx);
get_fpu(X86EMUL_FPU_ymm, &fic);
}
@@ -5673,6 +5673,7 @@ x86_emulate(
}
else
{
+generate_exception_if(vex.reg != 0xf, EXC_UD);
host_and_vcpu_must_have(avx);
get_fpu(X86EMUL_FPU_ymm, &fic);
}
@@ -6273,6 +6274,7 @@ x86_emulate(
case X86EMUL_OPC_VEX(0x0f, 0x77):/* vzero{all,upper} */
if ( vex.opcx != vex_none )
{
+generate_exception_if(vex.reg != 0xf, EXC_UD);
host_and_vcpu_must_have(avx);
get_fpu(X86EMUL_FPU_ymm, &fic);
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] xen: Allow a default compiled-in command line using Kconfig
Hi Jan, On 08/03/17 08:03, Jan Beulich wrote: On 07.03.17 at 18:48, wrote: Here some concrete examples. The major bootloaders on ARM today are: * UEFI * U-boot * GRUB I will leave UEFI aside as people will usually chainload to GRUB and then boot whatever they want. In both GRUB and U-boot a user will be able to modify the command line from the bootloader shell. Thanks. So I think the takeaway is that ARM doesn't strictly need the Dom0 part of the handling, but then again if this was common code it also shouldn't hurt. Correct. As long as the he expected behavior (e.g how they options are combined) is fully documented. Note that I was not able to find any documentation about this in xen-commandline.markdown. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/7] xen/9pfs: connect to the backend
Hi Stefano, On 08/03/17 00:49, Stefano Stabellini wrote: On Tue, 7 Mar 2017, Julien Grall wrote: On 03/06/2017 08:01 PM, Stefano Stabellini wrote: + if (ring->bytes == NULL) + goto error; + for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++) + ring->intf->ref[i] = gnttab_grant_foreign_access(dev->otherend_id, pfn_to_gfn(virt_to_pfn((void*)ring->bytes) + i), 0);. Please use virt_to_gfn rather than pfn_to_gfn(virt_to_pfn). OK Also, this is not going to work on 64K kernel because you will grant access to noncontiguous memory (e.g 0-4K, 64K-68K,...). By using virt_to_gfn like you suggested, the loop will correctly iterate on a 4K by 4K basis, even on a 64K kernel: ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO, XEN_9PFS_RING_ORDER - (PAGE_SHIFT - XEN_PAGE_SHIFT)); for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++) ring->intf->ref[i] = gnttab_grant_foreign_access(dev->otherend_id, virt_to_gfn((void*)ring->bytes) + i, 0); BTW, the cast (void *) is not necessary. where XEN_9PFS_RING_ORDER specifies the order at 4K granularity. Am I missing something? I think it is fine. You could move virt_to_gfn(...) outside and avoid to do the translation everytime. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen 4.7.2 released
All, I am pleased to announce the release of Xen 4.7.2. This is available immediately from its git repository http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7 (tag RELEASE-4.7.2) or from the XenProject download page http://www.xenproject.org/downloads/xen-archives/xen-47-series/xen-472.html (where a list of changes can also be found). We recommend all users of the 4.7 stable series to update to this latest point release. Regards, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen 4.6.5 released
All, I am pleased to announce the release of Xen 4.6.5. This is available immediately from its git repository http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6 (tag RELEASE-4.6.5) or from the XenProject download page http://www.xenproject.org/downloads/xen-archives/xen-46-series/xen-465.html (where a list of changes can also be found). We recommend all users of the 4.6 stable series to update to this latest point release. Regards, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/emul: Avoid #UD in SIMD stubs
>>> On 08.03.17 at 13:10, wrote:
> v{,u}comis{s,d}, and vcvt{,t}s{s,d}2si are two-operand instructions, while
> vzero{all,upper} take no operands, so require vex.reg set to ~0 to avoid
> #UD.
>
> Spotted while fuzzing with AFL
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/emul: Avoid #UD in SIMD stubs
On 08/03/17 13:02, Jan Beulich wrote:
On 08.03.17 at 13:10, wrote:
>> v{,u}comis{s,d}, and vcvt{,t}s{s,d}2si are two-operand instructions, while
>> vzero{all,upper} take no operands, so require vex.reg set to ~0 to avoid
>> #UD.
>>
>> Spotted while fuzzing with AFL
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
>
>
Thanks,
I took this opportunity to test the stub recovery from the point of view
of a malicious guest.
(XEN) d2v0 exception 6 (ec=) in emulation stub (line 6239)
(XEN) d2v0 stub: c4 e1 44 77 c3 80 d0 82 ff ff ff d1 90 ec 90
It is good to see that such a bug won't even been a security issue in
Xen 4.9!
One observation however. It would probably be safer to poison the stub
with 0xcc each time (especially if we have a path which omits the ret),
instead of leaving partial instructions in place.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/emul: Avoid #UD in SIMD stubs
>>> On 08.03.17 at 14:24, wrote: > One observation however. It would probably be safer to poison the stub > with 0xcc each time (especially if we have a path which omits the ret), > instead of leaving partial instructions in place. I too have been considering this. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/7] xen/9pfs: connect to the backend
>
>>> + ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
>>> XEN_9PFS_RING_ORDER);
>>> + if (ring->bytes == NULL)
>>> + goto error;
>>> + for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
>>> + ring->intf->ref[i] =
>>> gnttab_grant_foreign_access(dev->otherend_id,
>>> pfn_to_gfn(virt_to_pfn((void*)ring->bytes) + i), 0);
>>> + ring->ref = gnttab_grant_foreign_access(dev->otherend_id,
>>> pfn_to_gfn(virt_to_pfn((void*)ring->intf)), 0);
>>> + ring->ring.in = ring->bytes;
>>> + ring->ring.out = ring->bytes + XEN_9PFS_RING_SIZE;
>>> +
>>> + ret = xenbus_alloc_evtchn(dev, &ring->evtchn);
>>> + if (ret)
>>> + goto error;
>>> + ring->irq = bind_evtchn_to_irqhandler(ring->evtchn,
>>> xen_9pfs_front_event_handler,
>>> + 0, "xen_9pfs-frontend", ring);
>>> + if (ring->irq < 0) {
>>> + xenbus_free_evtchn(dev, ring->evtchn);
>>> + ret = ring->irq;
>>> + goto error;
>>> + }
>>> return 0;
>>> +
>>> +error:
>> You may need to gnttab_end_foreign_access().
> Actually this error path is unnecessary because it will be handled by
> xen_9pfs_front_probe, that calls xen_9pfs_front_free on errors. I'll
> remove it.
(It's a matter of personal preference but I think a routine should clean
up its own mess whenever it can.)
>
>
> +
> + again:
> + ret = xenbus_transaction_start(&xbt);
> + if (ret) {
> + xenbus_dev_fatal(dev, ret, "starting transaction");
> + goto error;
> + }
> + ret = xenbus_printf(xbt, dev->nodename, "version", "%u", 1);
> + if (ret)
> + goto error_xenbus;
> + ret = xenbus_printf(xbt, dev->nodename, "num-rings", "%u",
> priv->num_rings);
> + if (ret)
> + goto error_xenbus;
> + for (i = 0; i < priv->num_rings; i++) {
> + char str[16];
> +
> + priv->rings[i].priv = priv;
> + ret = xen_9pfs_front_alloc_dataring(dev, &priv->rings[i]);
>> Not for -EAGAIN, I think.
> I don't think xen_9pfs_front_alloc_dataring can return EAGAIN. EAGAIN
> can only come from xenbus_transaction_end, the case we handle below.
I didn't mean that xen_9pfs_front_alloc_dataring() can return -EAGAIN. I
was referring to...
>
>
>>> + if (ret < 0)
>>> + goto error_xenbus;
>>> +
>>> + sprintf(str, "ring-ref%u", i);
>>> + ret = xenbus_printf(xbt, dev->nodename, str, "%d",
>>> priv->rings[i].ref);
>>> + if (ret)
>>> + goto error_xenbus;
>>> +
>>> + sprintf(str, "event-channel-%u", i);
>>> + ret = xenbus_printf(xbt, dev->nodename, str, "%u",
>>> priv->rings[i].evtchn);
>>> + if (ret)
>>> + goto error_xenbus;
>>> + }
>>> + priv->tag = xenbus_read(xbt, dev->nodename, "tag", NULL);
>>> + if (ret)
>>> + goto error_xenbus;
>>> + ret = xenbus_transaction_end(xbt, 0);
>>> + if (ret) {
>>> + if (ret == -EAGAIN)
>>> + goto again;
... this.
Sorry for not being clear.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
> On 03/06/2017 03:21 PM, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > > The subject is wrong, should be something like "scsi: libfc convert > fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390. > > Other than that > Acked-by: Johannes Thumshirn Turns out that it is better that all these patches go through the respective maintainer trees, if present. If I send an updated patch (with subject fixed), could you merge it through your tree? Best Regards, Elena. > > -- > Johannes Thumshirn Storage > jthumsh...@suse.de+49 911 74053 689 > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) > Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t
> On 03/06/2017 09:21 AM, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > > situations. > > > > Signed-off-by: Elena Reshetova > > Signed-off-by: Hans Liljestrand > > Signed-off-by: Kees Cook > > Signed-off-by: David Windsor > > --- > > drivers/xen/gntdev.c | 11 ++- > > 1 file changed, 6 insertions(+), 5 deletions(-) > > Reviewed-by: Boris Ostrovsky Is there a tree that can take this change? Turns out it is better to propagate changes via separate trees and only leftovers can be taken via Greg's tree. Best Regards, Elena. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 3/5] x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server pages.
In ept_handle_violation(), write violations are also treated as
read violations. And when a VM is accessing a write-protected
address with read-modify-write instructions, the read emulation
process is triggered first.
For p2m_ioreq_server pages, current ioreq server only forwards
the write operations to the device model. Therefore when such page
is being accessed by a read-modify-write instruction, the read
operations should be emulated here in hypervisor. This patch provides
such a handler to copy the data to the buffer.
Note: MMIOs with p2m_mmio_dm type do not need such special treatment
because both reads and writes will go to the device mode.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
changes in v2:
- According to comments from Jan: rename mem_ops to ioreq_server_ops.
- According to comments from Jan: use hvm_copy_from_guest_phys() in
ioreq_server_read(), instead of do it by myself.
---
xen/arch/x86/hvm/emulate.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index fb56f7b..9744dcb 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -94,6 +94,26 @@ static const struct hvm_io_handler null_handler = {
.ops = &null_ops
};
+static int ioreq_server_read(const struct hvm_io_handler *io_handler,
+uint64_t addr,
+uint32_t size,
+uint64_t *data)
+{
+if ( hvm_copy_from_guest_phys(data, addr, size) != HVMCOPY_okay )
+return X86EMUL_UNHANDLEABLE;
+
+return X86EMUL_OKAY;
+}
+
+static const struct hvm_io_ops ioreq_server_ops = {
+.read = ioreq_server_read,
+.write = null_write
+};
+
+static const struct hvm_io_handler ioreq_server_handler = {
+.ops = &ioreq_server_ops
+};
+
static int hvmemul_do_io(
bool_t is_mmio, paddr_t addr, unsigned long *reps, unsigned int size,
uint8_t dir, bool_t df, bool_t data_is_addr, uintptr_t data)
@@ -197,6 +217,10 @@ static int hvmemul_do_io(
* - If the IOREQ_MEM_ACCESS_WRITE flag is not set, treat it
* like a normal PIO or MMIO that doesn't have an ioreq
* server (i.e., by ignoring it).
+ *
+ * - If the accesss is a read, this could be part of a
+ * read-modify-write instruction, emulate the read so that we
+ * have it.
*/
struct hvm_ioreq_server *s = NULL;
p2m_type_t p2mt = p2m_invalid;
@@ -226,6 +250,17 @@ static int hvmemul_do_io(
}
/*
+ * This is part of a read-modify-write instruction.
+ * Emulate the read part so we have the value cached.
+ */
+if ( dir == IOREQ_READ )
+{
+rc = hvm_process_io_intercept(&ioreq_server_handler, &p);
+vio->io_req.state = STATE_IOREQ_NONE;
+break;
+}
+
+/*
* If the IOREQ_MEM_ACCESS_WRITE flag is not set,
* we should set s to NULL, and just ignore such
* access.
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 0/5] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.
XenGT leverages ioreq server to track and forward the accesses to GPU I/O resources, e.g. the PPGTT(per-process graphic translation tables). Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges to be emulated. To select an ioreq server, the rangeset is searched to see if the I/O range is recorded. However, number of ram pages to be tracked may exceed the upper limit of rangeset. Previously, one solution was proposed to refactor the rangeset, and extend its upper limit. However, after 12 rounds discussion, we have decided to drop this approach due to security concerns. Now this new patch series introduces a new mem type, HVMMEM_ioreq_server, and added hvm operations to let one ioreq server to claim its ownership of ram pages with this type. Accesses to a page of this type will be handled by the specified ioreq server directly. Yu Zhang (5): x86/ioreq server: Release the p2m lock after mmio is handled. x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server. x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server pages. ix86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries. x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps. xen/arch/x86/hvm/dm.c| 79 +++-- xen/arch/x86/hvm/emulate.c | 99 ++- xen/arch/x86/hvm/hvm.c | 8 +-- xen/arch/x86/hvm/ioreq.c | 46 +++ xen/arch/x86/mm/hap/hap.c| 9 +++ xen/arch/x86/mm/hap/nested_hap.c | 2 +- xen/arch/x86/mm/p2m-ept.c| 16 - xen/arch/x86/mm/p2m-pt.c | 33 --- xen/arch/x86/mm/p2m.c| 123 +++ xen/arch/x86/mm/shadow/multi.c | 3 +- xen/include/asm-x86/hvm/ioreq.h | 2 + xen/include/asm-x86/p2m.h| 40 +++-- xen/include/public/hvm/dm_op.h | 29 - xen/include/public/hvm/hvm_op.h | 8 ++- 14 files changed, 463 insertions(+), 34 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.
Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
select the ioreq server. For example, operations on gfns with
p2m_ioreq_server type will be delivered to a corresponding ioreq
server, and this requires that the p2m type not be switched back
to p2m_ram_rw during the emulation process. To avoid this race
condition, we delay the release of p2m lock in hvm_hap_nested_page_fault()
until mmio is handled.
Note: previously in hvm_hap_nested_page_fault(), put_gfn() was moved
before the handling of mmio, due to a deadlock risk between the p2m
lock and the event lock(in commit 77b8dfe). Later, a per-event channel
lock was introduced in commit de6acb7, to send events. So we do not
need to worry about the deadlock issue.
Signed-off-by: Yu Zhang
Reviewed-by: Jan Beulich
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ccfae4f..a9db7f7 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
long gla,
(npfec.write_access &&
(p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
{
-__put_gfn(p2m, gfn);
-if ( ap2m_active )
-__put_gfn(hostp2m, gfn);
-
rc = 0;
if ( unlikely(is_pvh_domain(currd)) )
-goto out;
+goto out_put_gfn;
if ( !handle_mmio_with_translation(gla, gpa >> PAGE_SHIFT, npfec) )
hvm_inject_hw_exception(TRAP_gp_fault, 0);
rc = 1;
-goto out;
+goto out_put_gfn;
}
/* Check if the page has been paged out */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 2/5] x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server.
A new DMOP - XEN_DMOP_map_mem_type_to_ioreq_server, is added to let one ioreq server claim/disclaim its responsibility for the handling of guest pages with p2m type p2m_ioreq_server. Users of this DMOP can specify which kind of operation is supposed to be emulated in a parameter named flags. Currently, this DMOP only support the emulation of write operations. And it can be further extended to support the emulation of read ones if an ioreq server has such requirement in the future. For now, we only support one ioreq server for this p2m type, so once an ioreq server has claimed its ownership, subsequent calls of the XEN_DMOP_map_mem_type_to_ioreq_server will fail. Users can also disclaim the ownership of guest ram pages with p2m_ioreq_server, by triggering this new DMOP, with ioreq server id set to the current owner's and flags parameter set to 0. Note both XEN_DMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server are only supported for HVMs with HAP enabled. Also note that only after one ioreq server claims its ownership of p2m_ioreq_server, will the p2m type change to p2m_ioreq_server be allowed. Signed-off-by: Paul Durrant Signed-off-by: Yu Zhang Acked-by: Tim Deegan --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Paul Durrant Cc: George Dunlap Cc: Jun Nakajima Cc: Kevin Tian Cc: Tim Deegan changes in v7: - Use new ioreq server interface - XEN_DMOP_map_mem_type_to_ioreq_server. - According to comments from George: removed domain_pause/unpause() in hvm_map_mem_type_to_ioreq_server(), because it's too expensive, and we can avoid the: a> deadlock between p2m lock and ioreq server lock by using these locks in the same order - solved in patch 4; b> for race condition between vm exit and ioreq server unbinding, we can just retry this instruction. - According to comments from Jan and George: continue to clarify logic in hvmemul_do_io(). - According to comments from Jan: clarify comment in p2m_set_ioreq_server(). changes in v6: - Clarify logic in hvmemul_do_io(). - Use recursive lock for ioreq server lock. - Remove debug print when mapping ioreq server. - Clarify code in ept_p2m_type_to_flags() for consistency. - Remove definition of P2M_IOREQ_HANDLE_WRITE_ACCESS. - Add comments for HVMMEM_ioreq_server to note only changes to/from HVMMEM_ram_rw are permitted. - Add domain_pause/unpause() in hvm_map_mem_type_to_ioreq_server() to avoid the race condition when a vm exit happens on a write- protected page, just to find the ioreq server has been unmapped already. - Introduce a seperate patch to delay the release of p2m lock to avoid the race condition. - Introduce a seperate patch to handle the read-modify-write operations on a write protected page. changes in v5: - Simplify logic in hvmemul_do_io(). - Use natual width types instead of fixed width types when possible. - Do not grant executable permission for p2m_ioreq_server entries. - Clarify comments and commit message. - Introduce a seperate patch to recalculate the p2m types after the ioreq server unmaps the p2m_ioreq_server. changes in v4: - According to Paul's advice, add comments around the definition of HVMMEM_iore_server in hvm_op.h. - According to Wei Liu's comments, change the format of the commit message. changes in v3: - Only support write emulation in this patch; - Remove the code to handle race condition in hvmemul_do_io(), - No need to reset the p2m type after an ioreq server has disclaimed its ownership of p2m_ioreq_server; - Only allow p2m type change to p2m_ioreq_server after an ioreq server has claimed its ownership of p2m_ioreq_server; - Only allow p2m type change to p2m_ioreq_server from pages with type p2m_ram_rw, and vice versa; - HVMOP_map_mem_type_to_ioreq_server interface change - use uint16, instead of enum to specify the memory type; - Function prototype change to p2m_get_ioreq_server(); - Coding style changes; - Commit message changes; - Add Tim's Acked-by. changes in v2: - Only support HAP enabled HVMs; - Replace p2m_mem_type_changed() with p2m_change_entry_type_global() to reset the p2m type, when an ioreq server tries to claim/disclaim its ownership of p2m_ioreq_server; - Comments changes. --- xen/arch/x86/hvm/dm.c| 40 -- xen/arch/x86/hvm/emulate.c | 64 -- xen/arch/x86/hvm/ioreq.c | 38 + xen/arch/x86/mm/hap/nested_hap.c | 2 +- xen/arch/x86/mm/p2m-ept.c| 8 - xen/arch/x86/mm/p2m-pt.c | 20 +++ xen/arch/x86/mm/p2m.c| 74 xen/arch/x86/mm/shadow/multi.c | 3 +- xen/include/asm-x86/hvm/ioreq.h | 2 ++ xen/include/asm-x86/p2m.h| 26 -- xen/include/public/hvm/dm_op.h | 26 ++ xen/include/public/hvm/hvm_op.h | 8 - 12 files changed, 292 ins
[Xen-devel] [PATCH v7 5/5] x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.
After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
synchronously by iterating the p2m table.
The synchronous resetting is necessary because we need to guarantee
the p2m table is clean before another ioreq server is mapped. And
since the sweeping of p2m table could be time consuming, it is done
with hypercall continuation.
Signed-off-by: Yu Zhang
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
changes in v1:
- This patch is splitted from patch 4 of last version.
- According to comments from Jan: update the gfn_start for
when use hypercall continuation to reset the p2m type.
- According to comments from Jan: use min() to compare gfn_end
and max mapped pfn in p2m_finish_type_change()
---
xen/arch/x86/hvm/dm.c | 43 +-
xen/arch/x86/mm/p2m.c | 29
xen/include/asm-x86/p2m.h | 5 +
xen/include/public/hvm/dm_op.h | 3 +--
4 files changed, 73 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index f97478b..a92d5d7 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -288,6 +288,7 @@ static int inject_event(struct domain *d,
return 0;
}
+#define DMOP_op_mask 0xff
static int dm_op(domid_t domid,
unsigned int nr_bufs,
xen_dm_op_buf_t bufs[])
@@ -315,10 +316,8 @@ static int dm_op(domid_t domid,
}
rc = -EINVAL;
-if ( op.pad )
-goto out;
-switch ( op.op )
+switch ( op.op & DMOP_op_mask )
{
case XEN_DMOP_create_ioreq_server:
{
@@ -387,6 +386,10 @@ static int dm_op(domid_t domid,
{
const struct xen_dm_op_map_mem_type_to_ioreq_server *data =
&op.u.map_mem_type_to_ioreq_server;
+unsigned long gfn_start = op.op & ~DMOP_op_mask;
+unsigned long gfn_end;
+
+const_op = false;
rc = -EINVAL;
if ( data->pad )
@@ -396,8 +399,38 @@ static int dm_op(domid_t domid,
if ( !hap_enabled(d) )
break;
-rc = hvm_map_mem_type_to_ioreq_server(d, data->id,
- data->type, data->flags);
+if ( gfn_start == 0 )
+rc = hvm_map_mem_type_to_ioreq_server(d, data->id,
+ data->type, data->flags);
+/*
+ * Iterate p2m table when an ioreq server unmaps from p2m_ioreq_server,
+ * and reset the remaining p2m_ioreq_server entries back to p2m_ram_rw.
+ */
+if ( (gfn_start > 0) || (data->flags == 0 && rc == 0) )
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+while ( read_atomic(&p2m->ioreq.entry_count) &&
+gfn_start <= p2m->max_mapped_pfn )
+{
+gfn_end = gfn_start + DMOP_op_mask;
+
+p2m_finish_type_change(d, gfn_start, gfn_end,
+ p2m_ioreq_server, p2m_ram_rw);
+
+gfn_start = gfn_end + 1;
+
+/* Check for continuation if it's not the last iteration. */
+if ( gfn_start <= p2m->max_mapped_pfn &&
+ hypercall_preempt_check() )
+{
+rc = -ERESTART;
+op.op |= gfn_start;
+break;
+}
+}
+}
+
break;
}
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 94d7141..9a81f00 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1038,6 +1038,35 @@ void p2m_change_type_range(struct domain *d,
p2m_unlock(p2m);
}
+/* Synchronously modify the p2m type of a range of gfns from ot to nt. */
+void p2m_finish_type_change(struct domain *d,
+unsigned long start, unsigned long end,
+p2m_type_t ot, p2m_type_t nt)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+p2m_type_t t;
+unsigned long gfn = start;
+
+ASSERT(start <= end);
+ASSERT(ot != nt);
+ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
+
+p2m_lock(p2m);
+
+end = min(end, p2m->max_mapped_pfn);
+while ( gfn <= end )
+{
+get_gfn_query_unlocked(d, gfn, &t);
+
+if ( t == ot )
+p2m_change_type_one(d, gfn, t, nt);
+
+gfn++;
+}
+
+p2m_unlock(p2m);
+}
+
/*
* Returns:
*0 for success
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 395f125..3eadd89 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -611,6 +611,11 @@ void p2m_change_type_range(struct domain *d,
int p2m_change_type_one(struct domain *d, unsigned long gfn,
p2m_type_t ot, p2m_type_t nt);
+/* Synchronously change types across a range of p2m entries (start ... end) */
[Xen-devel] [xen-4.7-testing test] 106540: tolerable FAIL - PUSHED
flight 106540 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/106540/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 9 debian-install fail blocked in 106251 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 106251 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106251 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106251 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106251 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 106251 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 106251 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-arm64-xsm 5 xen-buildfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass build-arm64 5 xen-buildfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: xen 8b7ab1eac8a088bf7c247e763ae58105980f84ee baseline version: xen 8550b69ba41a5b3a0aa766b91d041eeb2bc4993e Last test of basis 106251 2017-02-28 10:11:09 Z8 days Failing since106528 2017-03-07 16:41:45 Z0 days2 attempts Testing same since 106540 2017-03-07 23:18:25 Z0 days1 attempts People who touched revisions under test: Edgar E. Iglesias Jan Beulich Stefano Stabellini jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-am
[Xen-devel] [PATCH v7 4/5] ix86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.
After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
asynchronously with the current p2m_change_entry_type_global()
interface.
This patch also disallows live migration, when there's still any
outstanding p2m_ioreq_server entry left. The core reason is our
current implementation of p2m_change_entry_type_global() can not
tell the state of p2m_ioreq_server entries(can not decide if an
entry is to be emulated or to be resynced).
Signed-off-by: Yu Zhang
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jun Nakajima
Cc: Kevin Tian
changes in v3:
- Move the synchronously resetting logic into patch 5.
- According to comments from Jan: introduce p2m_check_changeable()
to clarify the p2m type change code.
- According to comments from George: use locks in the same order
to avoid deadlock, call p2m_change_entry_type_global() after unmap
of the ioreq server is finished.
changes in v2:
- Move the calculation of ioreq server page entry_cout into
p2m_change_type_one() so that we do not need a seperate lock.
Note: entry_count is also calculated in resolve_misconfig()/
do_recalc(), fortunately callers of both routines have p2m
lock protected already.
- Simplify logic in hvmop_set_mem_type().
- Introduce routine p2m_finish_type_change() to walk the p2m
table and do the p2m reset.
---
xen/arch/x86/hvm/ioreq.c | 8
xen/arch/x86/mm/hap/hap.c | 9 +
xen/arch/x86/mm/p2m-ept.c | 8 +++-
xen/arch/x86/mm/p2m-pt.c | 13 +++--
xen/arch/x86/mm/p2m.c | 20
xen/include/asm-x86/p2m.h | 9 -
6 files changed, 63 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index fcb9f38..c129eb4 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -949,6 +949,14 @@ int hvm_map_mem_type_to_ioreq_server(struct domain *d,
ioservid_t id,
spin_unlock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
+if ( rc == 0 && flags == 0 )
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+if ( read_atomic(&p2m->ioreq.entry_count) )
+p2m_change_entry_type_global(d, p2m_ioreq_server, p2m_ram_rw);
+}
+
return rc;
}
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index a57b385..f27a56f 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -187,6 +187,15 @@ out:
*/
static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+/*
+* Refuse to turn on global log-dirty mode if
+* there's outstanding p2m_ioreq_server pages.
+*/
+if ( log_global && read_atomic(&p2m->ioreq.entry_count) )
+return -EBUSY;
+
/* turn on PG_log_dirty bit in paging mode */
paging_lock(d);
d->arch.paging.mode |= PG_log_dirty;
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index cc1eb21..1df3d09 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -544,6 +544,12 @@ static int resolve_misconfig(struct p2m_domain *p2m,
unsigned long gfn)
e.ipat = ipat;
if ( e.recalc && p2m_is_changeable(e.sa_p2mt) )
{
+ if ( e.sa_p2mt == p2m_ioreq_server )
+ {
+ p2m->ioreq.entry_count--;
+ ASSERT(p2m->ioreq.entry_count >= 0);
+ }
+
e.sa_p2mt = p2m_is_logdirty_range(p2m, gfn + i, gfn +
i)
? p2m_ram_logdirty : p2m_ram_rw;
ept_p2m_type_to_flags(p2m, &e, e.sa_p2mt, e.access);
@@ -965,7 +971,7 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
if ( is_epte_valid(ept_entry) )
{
if ( (recalc || ept_entry->recalc) &&
- p2m_is_changeable(ept_entry->sa_p2mt) )
+ p2m_check_changeable(ept_entry->sa_p2mt) )
*t = p2m_is_logdirty_range(p2m, gfn, gfn) ? p2m_ram_logdirty
: p2m_ram_rw;
else
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 97dc25d..d9a7b76 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -437,11 +437,13 @@ static int do_recalc(struct p2m_domain *p2m, unsigned
long gfn)
needs_recalc(l1, *pent) )
{
l1_pgentry_t e = *pent;
+p2m_type_t p2mt_old;
if ( !valid_recalc(l1, e) )
P2M_DEBUG("bogus recalc leaf at d%d:%lx:%u\n",
p2m->domain->domain_id, gfn, level);
-if ( p2m_is_changeable(p2m_flags_to_type(l1e_get_flags(e))) )
+p2mt_old = p2m_flags_to_type(l1e_get_flags(e));
+if ( p2m_is_changeable(p2mt_old) )
{
unsigned long mask = ~
Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup
Hi George, On 06/03/17 14:48, George Dunlap wrote: On 06/03/17 13:21, Julien Grall wrote: Hi Jan, On 06/03/17 12:41, Jan Beulich wrote: On 06.03.17 at 12:42, wrote: I thought a bit more about those params. I think the name should be generic and not tie to pl011 because we may want to emulate different UART for the guest in the future. That's reasonable, but I continue to have reservations against the underlying approach here, namely ... Also, by re-using deprecated encoding it means that it will not be possible to use those parameters on x86 if you ever decide to emulate UART in Xen. I am not sure whether if you are happy with that? ... with this in mind: If we wanted to do this for HVM guests, we'd indeed want the parameters. If we wanted this for PV guests, the model wouldn't fit at all. Plus what I'm not understanding (perhaps because most of the discussion around this seemed to be ARM-specific, and hence I've skipped reading through it) is - why is this UART emulation needed in the first place? We've never had a need for such on x86, afaia. Linaro has published a set of guidelines to guarantee a same guest image can run on multiple hypervisors (see [1]). This specification mandates the presence of a SBSA-compliant UART. I just realized the cover letter does not explain why we need to emulate a PL011 on ARM. Bhupinder can you detail it on the next version? Right, but in order to evaluate your question about whether we're "happy" with not being able to use these parameters if we ever decide to emulate UART on x86, we need to know a reason that one might decide to add a UART *on x86*, not on ARM. I mean, I don't think we're running out of bits, so I don't think it's a problem allocating new HVM_PARAM numbers so that we can re-use them if we ever decide to implement UARTs on x86. On the other hand, given that nobody has ever suggested doing so or knows why it might be useful, maybe it makes more sense to just re-use some x86 params and allocate extra numbers if / when we decide we want to implement UART on x86. I agree that the reason I gave is very ARM focused. I don't know what is the future on Xen for x86, but on ARM we have another potential use case for the UART emulation which I think could also apply for x86. On ARM, the guest is booting through the same path as on native. All the devices are discovered through the firmware tables. So it would be possible to run a guest OS without any knowledge of Xen if you assign all the necessary physical devices (e.g disk, network, serial...). Often you want to log the console of all your guests and keep them safely in the controller domain. This is where an emulated UART can be useful, you don't need to add Xen drivers in the guest and still can use the guest seamlessly via xl. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86emul: correct vzero{all, upper} for non-64-bit-mode
The registers only accessible in 64-bit mode need to be left alone in
this case.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -2910,6 +2910,45 @@ int main(int argc, char **argv)
else
printf("skipped\n");
+#ifdef __x86_64__
+printf("%-40s", "Testing vzeroupper (compat)...");
+if ( cpu_has_avx )
+{
+decl_insn(vzeroupper);
+
+ctxt.sp_size = ctxt.addr_size = 32;
+
+asm volatile ( "vxorps %xmm2, %xmm2, %xmm3\n"
+ "vcmpeqps %ymm3, %ymm3, %ymm4\n"
+ "vmovaps %ymm4, %ymm9\n"
+ put_insn(vzeroupper, "vzeroupper") );
+
+set_insn(vzeroupper);
+rc = x86_emulate(&ctxt, &emulops);
+if ( rc != X86EMUL_OKAY || !check_eip(vzeroupper) )
+goto fail;
+
+/* XMM0...XMM7 should have their high parts cleared. */
+asm ( "vextractf128 $1, %%ymm4, %%xmm0\n\t"
+ "vpmovmskb %%xmm4, %0\n\t"
+ "vpmovmskb %%xmm0, %1" : "=r" (rc), "=r" (i) );
+if ( rc != 0x || i )
+goto fail;
+
+/* XMM8...XMM15 should have their high parts preserved. */
+asm ( "vextractf128 $1, %%ymm9, %%xmm1\n\t"
+ "vpmovmskb %%xmm9, %0\n\t"
+ "vpmovmskb %%xmm1, %1" : "=r" (rc), "=r" (i) );
+if ( rc != 0x || i != 0x )
+goto fail;
+printf("okay\n");
+
+ctxt.sp_size = ctxt.addr_size = 64;
+}
+else
+printf("skipped\n");
+#endif
+
#undef decl_insn
#undef put_insn
#undef set_insn
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6277,6 +6277,45 @@ x86_emulate(
generate_exception_if(vex.reg != 0xf, EXC_UD);
host_and_vcpu_must_have(avx);
get_fpu(X86EMUL_FPU_ymm, &fic);
+
+#ifdef __x86_64__
+if ( !mode_64bit() )
+{
+/*
+ * Can't use the actual instructions here, as we must not
+ * touch YMM8...YMM15.
+ */
+if ( vex.l )
+{
+/* vpxor %xmmN, %xmmN, %xmmN */
+asm volatile ( ".byte 0xc5,0xf9,0xef,0xc0" );
+asm volatile ( ".byte 0xc5,0xf1,0xef,0xc9" );
+asm volatile ( ".byte 0xc5,0xe9,0xef,0xd2" );
+asm volatile ( ".byte 0xc5,0xe1,0xef,0xdb" );
+asm volatile ( ".byte 0xc5,0xd9,0xef,0xe4" );
+asm volatile ( ".byte 0xc5,0xd1,0xef,0xed" );
+asm volatile ( ".byte 0xc5,0xc9,0xef,0xf6" );
+asm volatile ( ".byte 0xc5,0xc1,0xef,0xff" );
+}
+else
+{
+/* vpor %xmmN, %xmmN, %xmmN */
+asm volatile ( ".byte 0xc5,0xf9,0xeb,0xc0" );
+asm volatile ( ".byte 0xc5,0xf1,0xeb,0xc9" );
+asm volatile ( ".byte 0xc5,0xe9,0xeb,0xd2" );
+asm volatile ( ".byte 0xc5,0xe1,0xeb,0xdb" );
+asm volatile ( ".byte 0xc5,0xd9,0xeb,0xe4" );
+asm volatile ( ".byte 0xc5,0xd1,0xeb,0xed" );
+asm volatile ( ".byte 0xc5,0xc9,0xeb,0xf6" );
+asm volatile ( ".byte 0xc5,0xc1,0xeb,0xff" );
+}
+
+put_fpu(&fic);
+
+ASSERT(!state->simd_size);
+break;
+}
+#endif
}
else
{
x86emul: correct vzero{all,upper} for non-64-bit-mode
The registers only accessible in 64-bit mode need to be left alone in
this case.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -2910,6 +2910,45 @@ int main(int argc, char **argv)
else
printf("skipped\n");
+#ifdef __x86_64__
+printf("%-40s", "Testing vzeroupper (compat)...");
+if ( cpu_has_avx )
+{
+decl_insn(vzeroupper);
+
+ctxt.sp_size = ctxt.addr_size = 32;
+
+asm volatile ( "vxorps %xmm2, %xmm2, %xmm3\n"
+ "vcmpeqps %ymm3, %ymm3, %ymm4\n"
+ "vmovaps %ymm4, %ymm9\n"
+ put_insn(vzeroupper, "vzeroupper") );
+
+set_insn(vzeroupper);
+rc = x86_emulate(&ctxt, &emulops);
+if ( rc != X86EMUL_OKAY || !check_eip(vzeroupper) )
+goto fail;
+
+/* XMM0...XMM7 should have their high parts cleared. */
+asm ( "vextractf128 $1, %%ymm4, %%xmm0\n\t"
+ "vpmovmskb %%xmm4, %0\n\t"
+ "vpmovmskb %%xmm0, %1" : "=r" (rc), "=r" (i) );
+if ( rc != 0x || i )
+goto fail;
+
+/* XMM8...XMM15 should have their high parts preserved. */
+asm ( "vextractf128 $1, %%ymm
Re: [Xen-devel] [PATCH 5/7] xen/9pfs: send requests to the backend
>>> +}
>>> +
>>> +static int p9_xen_write_todo(struct xen_9pfs_dataring *ring, RING_IDX size)
>>> +{
>>> + RING_IDX cons, prod;
>>> +
>>> + cons = ring->intf->out_cons;
>>> + prod = ring->intf->out_prod;
>>> + mb();
>>> +
>>> + if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons,
>>> XEN_9PFS_RING_SIZE) >= size)
>>> + return 1;
>>> + else
>>> + return 0;
>>> }
>>>
>>> static int p9_xen_request(struct p9_client *client, struct p9_req_t
>>> *p9_req)
>>> {
>>> + struct xen_9pfs_front_priv *priv = NULL;
>>> + RING_IDX cons, prod, masked_cons, masked_prod;
>>> + unsigned long flags;
>>> + uint32_t size = p9_req->tc->size;
>>> + struct xen_9pfs_dataring *ring;
>>> + int num;
>>> +
>>> + list_for_each_entry(priv, &xen_9pfs_devs, list) {
>>> + if (priv->client == client)
>>> + break;
>>> + }
>>> + if (priv == NULL || priv->client != client)
>>> + return -EINVAL;
>>> +
>>> + num = p9_req->tc->tag % priv->num_rings;
>>> + ring = &priv->rings[num];
>>> +
>>> +again:
>>> + while (wait_event_interruptible(ring->wq,
>>> + p9_xen_write_todo(ring, size) > 0) != 0);
>>> +
>>> + spin_lock_irqsave(&ring->lock, flags);
>>> + cons = ring->intf->out_cons;
>>> + prod = ring->intf->out_prod;
>>> + mb();
>>> +
>>> + if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons,
>>> XEN_9PFS_RING_SIZE) < size) {
>>
>> This looks like p9_xen_write_todo().
> p9_xen_write_todo is just a wrapper around xen_9pfs_queued to provide
> a return value that works well with wait_event_interruptible.
>
> I would prefer not to call p9_xen_write_todo here, because it's simpler
> if we don't read prod and cons twice.
I was referring to the whole code fragment after spin_lock_irqsave(),
not just the last line. Isn't it exactly !p9_xen_write_todo()?
>
>
>> BTW, where is xen_9pfs_queued()
>> defined? I couldn't find it. Same for xen_9pfs_mask() and
>> xen_9pfs_write_packet().
> They are provided by the new ring macros, see
> include/xen/interface/io/ring.h (the first patch).
Oh, right. I was searching for the string literally.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: correct vzero{all, upper} for non-64-bit-mode
On 08/03/17 13:56, Jan Beulich wrote: > The registers only accessible in 64-bit mode need to be left alone in > this case. > > Reported-by: Andrew Cooper > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Yu
> Zhang
> Sent: 08 March 2017 13:32
> To: xen-devel@lists.xen.org
> Cc: zhiyuan...@intel.com
> Subject: [Xen-devel] [PATCH v7 1/5] x86/ioreq server: Release the p2m lock
> after mmio is handled.
>
> Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
> select the ioreq server. For example, operations on gfns with
> p2m_ioreq_server type will be delivered to a corresponding ioreq
> server, and this requires that the p2m type not be switched back
> to p2m_ram_rw during the emulation process. To avoid this race
> condition, we delay the release of p2m lock in
> hvm_hap_nested_page_fault()
> until mmio is handled.
>
> Note: previously in hvm_hap_nested_page_fault(), put_gfn() was moved
> before the handling of mmio, due to a deadlock risk between the p2m
> lock and the event lock(in commit 77b8dfe). Later, a per-event channel
> lock was introduced in commit de6acb7, to send events. So we do not
> need to worry about the deadlock issue.
>
> Signed-off-by: Yu Zhang
> Reviewed-by: Jan Beulich
> ---
> Cc: Paul Durrant
> Cc: Jan Beulich
> Cc: Andrew Cooper
Your cc-s seem to have been dropped by your mailer (or at least I can't see
them in the mail header). You may want to send these again so that relevant
folks actually get cc-ed.
Paul
> ---
> xen/arch/x86/hvm/hvm.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index ccfae4f..a9db7f7 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
> unsigned long gla,
> (npfec.write_access &&
>(p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
> {
> -__put_gfn(p2m, gfn);
> -if ( ap2m_active )
> -__put_gfn(hostp2m, gfn);
> -
> rc = 0;
> if ( unlikely(is_pvh_domain(currd)) )
> -goto out;
> +goto out_put_gfn;
>
> if ( !handle_mmio_with_translation(gla, gpa >> PAGE_SHIFT, npfec) )
> hvm_inject_hw_exception(TRAP_gp_fault, 0);
> rc = 1;
> -goto out;
> +goto out_put_gfn;
> }
>
> /* Check if the page has been paged out */
> --
> 1.9.1
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t
On 03/08/2017 02:48 PM, Reshetova, Elena wrote: On 03/06/2017 03:21 PM, Elena Reshetova wrote: refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. The subject is wrong, should be something like "scsi: libfc convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390. Other than that Acked-by: Johannes Thumshirn Turns out that it is better that all these patches go through the respective maintainer trees, if present. If I send an updated patch (with subject fixed), could you merge it through your tree? Yes, but this would be the normal scsi tree from Martin and James. Please include my Ack in the re-sends. Thanks a lot, Johannes -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 106537: regressions - FAIL
flight 106537 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/106537/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 59254 test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254 test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 11 guest-start fail REGR. vs. 59254 test-armhf-armhf-libvirt-xsm 11 guest-start fail REGR. vs. 59254 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254 test-armhf-armhf-libvirt 11 guest-start fail REGR. vs. 59254 test-armhf-armhf-xl-arndale 11 guest-start fail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 11 guest-start fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 17 guest-start/win.repeat fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 59254 test-amd64-amd64-xl-rtds 9 debian-installfail REGR. vs. 59254 test-armhf-armhf-xl-vhd 9 debian-di-install fail baseline untested test-armhf-armhf-libvirt-raw 9 debian-di-install fail baseline untested test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass build-arm64 5 xen-buildfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux9e91c144e689bb780b412c2c7908b9cf7b96f31f baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 608 days Failing since 59348 2015-07-10 04:24:05 Z 607 days 320 attempts Testing same since 106537 2017-03-07 21:17:39 Z0 days1 attempts 8047 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass
Re: [Xen-devel] [PATCH v16 4/9] x86: add multiboot2 protocol support for EFI platforms
On Tue, Mar 07, 2017 at 10:44:15PM -0500, Konrad Rzeszutek Wilk wrote: > On Tue, Mar 07, 2017 at 12:39:04AM +0100, Daniel Kiper wrote: > > On Wed, Feb 22, 2017 at 09:04:17AM -0800, Doug Goldstein wrote: > > > > [...] > > > > > I'm currently at ELC and then on vacation so I don't have access to any > > > of the machines currently myself. However the machine I most use to test > > > is a NUC5i5MYHE and a NUC5i3MYHE if you want to ask around if someone > > > has one internally. But that's why I gave QEMU as an example. > > > > > > I was using qemu master from a few weeks ago. I'll have to find the > > > revision for you. But the command line I use is: > > > > > > -enable-kvm -M pc-q35-2.8 -device intel-iommu -cpu host -m 2048 -smp 2 > > > -drive if=pflash,format=raw,file=/tmp/tmp.EiR6ixmYzV -global > > > isa-debugcon.iobase=0x402 -debugcon file:/tmp/tmp.nuvEXUWfnA -monitor > > > stdio -chardev socket,host=127.0.0.1,port=25914,id=S0,server,nowait > > > -device isa-serial,chardev=S0 -device piix3-usb-uhci -device usb-tablet > > > -netdev id=net0,type=tap -device > > > virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56 -boot order=n -device > > > qxl-vga -gdb tcp::14952 > > > > Sadly, my colleagues and I are not able to reproduce the problem on any of > > machines available for us (available on the market and some development > > stuff in our labs). I did tests with QEMU (I am not able to run it with > > "-device intel-iommu" on my machine; I have to investigate this). Everything > > works. Joao did some tests on Intel NUC D34010WYK second generation. > > Everything works. So, Konrad ordered Intel NUC NUC5i3MYHE for me. I am > > waiting for delivery. Doug, could you tell me what distro, Xen, etc. you > > have installed on that NUC? I would like to test same config as yours on > > this machine. > > I had a chat with Doug on IRC and: > - I had tested earlier on AMD, while he has only Intel boxes, > - He was wondering if this was an IOMMU issue. I had and still have a feeling that it can be related to IOMMU. I will try to reproduce this on QEMU but first of all I have to check how to enable this option in my environment (something is broken). Additionally, there is a chance that the issue spotted by osstest (fixed right now) played a role here too. So, it will be nice if Doug can do tests with latest master. Anyway, I will do tests too. Though I am still waiting for my NUC. > So to double-check that, I installed Ubuntu 16.10 on my X11SAE > SuperMicro, which has an Haswell E3-1245 v5 and with IOMMU enabled. > > I tested the 'origin/staging' xen.gz build with the upstream grub2 > (I just used the 'master' branch) first and also just booting xen.efi. > > Both worked fine. > > Then I used v16 of Daniel's patches (this thread). They are also > now ongit://xenbits.xen.org/people/konradwilk/xen.git mb2.v16 > also the same way - as xen.efi and then using grub.efi and booting it > (see below) > > All worked fine. Great! Thanks a lot for doing the tests. > Now in the process I discovered that my patch for grub-mkconfig to > detect multiboot2 payloads and use those instead of multiboot never > made it upstream, so I had to modify my grub.cfg by hand (see below). It will be nice if you post it after GRUB2 2.02 release. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/7] xen/9pfs: receive responses
>
>>> +
>>> + if (xen_9pfs_queued(prod, cons, XEN_9PFS_RING_SIZE) <
>>> sizeof(h)) {
>>> + notify_remote_via_irq(ring->irq);
>>> + return;
>>> + }
>>> +
>>> + masked_prod = xen_9pfs_mask(prod, XEN_9PFS_RING_SIZE);
>>> + masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
>>> +
>>> + xen_9pfs_read_packet(ring->ring.in,
>>> + masked_prod, &masked_cons,
>>> + XEN_9PFS_RING_SIZE, &h, sizeof(h));
>>> +
>>> + req = p9_tag_lookup(priv->client, h.tag);
>>> + if (!req || req->status != REQ_STATUS_SENT) {
>>> + dev_warn(&priv->dev->dev, "Wrong req tag=%x\n", h.tag);
>>> + cons += h.size;
>>> + mb();
>>> + ring->intf->in_cons = cons;
>>> + continue;
>>
>> I don't know what xen_9pfs_read_packet() does so perhaps it's done there
>> but shouldn't the pointers be updated regardless of the 'if' condition?
> This is the error path - the index is increased immediately. In the
> non-error case, we do that right after the next read_packet call, few
> lines below.
>
>
>>> + }
>>> +
>>> + memcpy(req->rc, &h, sizeof(h));
>>> + req->rc->offset = 0;
>>> +
>>> + masked_cons = xen_9pfs_mask(cons, XEN_9PFS_RING_SIZE);
>>> + xen_9pfs_read_packet(ring->ring.in,
>>> + masked_prod, &masked_cons,
>>> + XEN_9PFS_RING_SIZE, req->rc->sdata, h.size);
>>> +
>>> + mb();
>>> + cons += h.size;
>>> + ring->intf->in_cons = cons;
>Here ^
>
So the second read is reading again from the same pointer in the ring,
but this time it gets the whole packet, including the header. The first
read was just poking at the header. Right?
If that's correct, can you add a comment somewhere? (unless this is
obvious to everyone else but me.)
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 106538: regressions - FAIL
flight 106538 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/106538/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963 version targeted for testing: ovmf 7babb4372e6a34cbbc54249b25056272a5a9924c baseline version: ovmf e0307a7dad02aa8c0cd8b3b0b9edce8ddb3fef2e Last test of basis 105963 2017-02-21 21:43:31 Z 14 days Failing since105980 2017-02-22 10:03:53 Z 14 days 39 attempts Testing same since 106527 2017-03-07 14:19:16 Z1 days2 attempts People who touched revisions under test: Anthony PERARD Ard Biesheuvel Bi, Dandan Brijesh Singh Chao Zhang Chen A Chen Dandan Bi edk2-devel On Behalf Of rthomaiy <[mailto:edk2-devel-boun...@lists.01.org]> Fu Siyuan Hao Wu Hegde Nagaraj P Jeff Fan Jiaxin Wu Jiewen Yao Laszlo Ersek Leo Duran Paolo Bonzini Qin Long Richard Thomaiyar Ruiyu Ni Star Zeng Wu Jiaxin Yonghong Zhu Zhang Lubo Zhang, Chao B jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 3309 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup
Hi Jan, On 06/03/17 13:48, Jan Beulich wrote: On 06.03.17 at 14:21, wrote: On 06/03/17 12:41, Jan Beulich wrote: Furthermore - how does this scale? I.e. what if other devices pop up wanting to be emulated? Or multiple UARTs? I think you can appreciate that using QEMU for emulating an UART is quite overkill. Sure, but this doesn't answer my questions. Devices we are planning to emulate are in order to be compliant with the SBSA. Looking at the spec, it requires: * SBSA UART * RTC: It is expected to drive through EFI API but we may want to also support in non-UEFI case. * Persistent environment storage: This is only required for the UEFI. Another device we are expecting to emulate in Xen is the PCI root complex in order to avoid as much as PV drivers for the guest. So I think we would need to emulate 3 devices: SBSA UART, RTC and root complex. I cannot predict what will happen in the future, but I would expect the number of devices we require to emulate very limited. Regarding the multiple UARTs, you have a point here. The code in itself could handle any number of UARTs easily, but we thought that guest will usually use only one console. I was looking at the backend code and see it is using DOMCTL command. I guess it is considered that the console backend will be tied to a specific Xen version. Am I correct? so maybe we can introduce new domctl command for handling vUART. This would avoid us to commit on an ABI and allow us to extend it if necessary in the future to support multiple UARTs. Any opinions? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 16/16] tools: adapt xenlight.pc and xlutil.pc to new pkg-config scheme
Instead of generating the *.pc.in files at configure time use the new pkg-config scheme for those files. Add the dependencies to other Xen libraries as needed. Signed-off-by: Juergen Gross --- .gitignore| 1 - tools/configure | 4 +--- tools/configure.ac| 2 -- tools/libxl/Makefile | 25 - tools/libxl/xenlight.pc.in| 12 tools/libxl/xenlight.pc.in.in | 11 --- tools/libxl/xlutil.pc.in | 10 ++ tools/libxl/xlutil.pc.in.in | 9 - 8 files changed, 43 insertions(+), 31 deletions(-) create mode 100644 tools/libxl/xenlight.pc.in delete mode 100644 tools/libxl/xenlight.pc.in.in create mode 100644 tools/libxl/xlutil.pc.in delete mode 100644 tools/libxl/xlutil.pc.in.in diff --git a/.gitignore b/.gitignore index 8606ba1..62012ef 100644 --- a/.gitignore +++ b/.gitignore @@ -193,7 +193,6 @@ tools/libxc/*.pc tools/libxl/_libxl.api-for-check tools/libxl/*.api-ok tools/libxl/*.pc -tools/libxl/*.pc.in tools/libxl/dsdt* tools/libxl/libxlu_cfg_y.output tools/libxl/mk_dsdt diff --git a/tools/configure b/tools/configure index 851e0f0..7a57e65 100755 --- a/tools/configure +++ b/tools/configure @@ -2411,7 +2411,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu -ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/FreeBSD/rc.d/xendriverdomain hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/sysconfig.xendomains hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/init.d/xendriverdomain hotplug/Linux/launch-xenstore hotplug/Linux/vif-setup hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons hotplug/NetBSD/rc.d/xendriverdomain libxl/xenlight.pc.in libxl/xlutil.pc.in ocaml/xenstored/oxenstored.conf" +ac_config_files="$ac_config_files ../config/Tools.mk hotplug/FreeBSD/rc.d/xencommons hotplug/FreeBSD/rc.d/xendriverdomain hotplug/Linux/init.d/sysconfig.xencommons hotplug/Linux/init.d/sysconfig.xendomains hotplug/Linux/init.d/xen-watchdog hotplug/Linux/init.d/xencommons hotplug/Linux/init.d/xendomains hotplug/Linux/init.d/xendriverdomain hotplug/Linux/launch-xenstore hotplug/Linux/vif-setup hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons hotplug/NetBSD/rc.d/xendriverdomain ocaml/xenstored/oxenstored.conf" ac_config_headers="$ac_config_headers config.h" @@ -10415,8 +10415,6 @@ do "hotplug/Linux/xendomains") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/xendomains" ;; "hotplug/NetBSD/rc.d/xencommons") CONFIG_FILES="$CONFIG_FILES hotplug/NetBSD/rc.d/xencommons" ;; "hotplug/NetBSD/rc.d/xendriverdomain") CONFIG_FILES="$CONFIG_FILES hotplug/NetBSD/rc.d/xendriverdomain" ;; -"libxl/xenlight.pc.in") CONFIG_FILES="$CONFIG_FILES libxl/xenlight.pc.in" ;; -"libxl/xlutil.pc.in") CONFIG_FILES="$CONFIG_FILES libxl/xlutil.pc.in" ;; "ocaml/xenstored/oxenstored.conf") CONFIG_FILES="$CONFIG_FILES ocaml/xenstored/oxenstored.conf" ;; "config.h") CONFIG_HEADERS="$CONFIG_HEADERS config.h" ;; "hotplug/Linux/systemd/proc-xen.mount") CONFIG_FILES="$CONFIG_FILES hotplug/Linux/systemd/proc-xen.mount" ;; diff --git a/tools/configure.ac b/tools/configure.ac index 28a539c..307998d 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -21,8 +21,6 @@ hotplug/Linux/xen-hotplug-common.sh hotplug/Linux/xendomains hotplug/NetBSD/rc.d/xencommons hotplug/NetBSD/rc.d/xendriverdomain -libxl/xenlight.pc.in -libxl/xlutil.pc.in ocaml/xenstored/oxenstored.conf ]) AC_CONFIG_HEADERS([config.h]) diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index f00d9ef..2524f57 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -189,6 +189,25 @@ SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn) PKG_CONFIG = xenlight.pc xlutil.pc +PKG_CONFIG_VERSION := $(MAJOR).$(MINOR) + +ifneq ($(CONFIG_LIBXC_MINIOS),y) +PKG_CONFIG_INST := $(PKG_CONFIG) +xenlight.pc: PKG_CONFIG_VERSION = $(MAJOR).$(MINOR) +xlutil.pc: PKG_CONFIG_VERSION = $(XLUMAJOR).$(XLUMINOR) +$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix) +$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir) +$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir) +endif + +PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc)) + +$(PKG_CONFIG_DIR)/xenlight.pc: PKG_CONFIG_VERSION = $(MAJOR).$(MINOR) +$(PKG_CONFIG_DIR)/xlutil.pc: PKG_CONFIG_VERSION = $(XLUMAJOR).$(XLUMINOR) +$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT) +$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(CURDIR) +$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR) +$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude) testidl.o: CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenlight) testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS) @@
[Xen-devel] [PATCH 05/16] tools: provide pkg-config file for libxentoollog
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xentoollog.pc file.
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
tools/libs/toollog/Makefile | 20 +++-
tools/libs/toollog/xentoollog.pc.in | 9 +
3 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 tools/libs/toollog/xentoollog.pc.in
diff --git a/.gitignore b/.gitignore
index 443b12a..374647c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -96,6 +96,7 @@ config/Tools.mk
config/Stubdom.mk
config/Docs.mk
tools/libs/toollog/headers.chk
+tools/libs/toollog/xentoollog.pc
tools/libs/evtchn/headers.chk
tools/libs/gnttab/headers.chk
tools/libs/call/headers.chk
diff --git a/tools/libs/toollog/Makefile b/tools/libs/toollog/Makefile
index fb701be..7361194 100644
--- a/tools/libs/toollog/Makefile
+++ b/tools/libs/toollog/Makefile
@@ -19,6 +19,22 @@ ifneq ($(nosharedlibs),y)
LIB += libxentoollog.so
endif
+PKG_CONFIG := xentoollog.pc
+PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
+
+ifneq ($(CONFIG_LIBXC_MINIOS),y)
+PKG_CONFIG_INST := $(PKG_CONFIG)
+$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix)
+$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir)
+$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir)
+endif
+
+PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENTOOLLOG)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+
.PHONY: all
all: build
@@ -27,7 +43,7 @@ build:
$(MAKE) libs
.PHONY: libs
-libs: headers.chk $(LIB)
+libs: headers.chk $(LIB) $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
headers.chk: $(wildcard include/*.h)
@@ -51,6 +67,7 @@ install: build
$(SYMLINK_SHLIB) libxentoollog.so.$(MAJOR).$(MINOR)
$(DESTDIR)$(libdir)/libxentoollog.so.$(MAJOR)
$(SYMLINK_SHLIB) libxentoollog.so.$(MAJOR)
$(DESTDIR)$(libdir)/libxentoollog.so
$(INSTALL_DATA) include/xentoollog.h $(DESTDIR)$(includedir)
+ $(INSTALL_DATA) xentoollog.pc $(DESTDIR)$(PKG_INSTALLDIR)
.PHONY: TAGS
TAGS:
@@ -61,6 +78,7 @@ clean:
rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS)
rm -f libxentoollog.so.$(MAJOR).$(MINOR) libxentoollog.so.$(MAJOR)
rm -f headers.chk
+ rm -f xentoollog.pc
.PHONY: distclean
distclean: clean
diff --git a/tools/libs/toollog/xentoollog.pc.in
b/tools/libs/toollog/xentoollog.pc.in
new file mode 100644
index 000..554e4d5
--- /dev/null
+++ b/tools/libs/toollog/xentoollog.pc.in
@@ -0,0 +1,9 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xentoollog
+Description: The Xentoollog library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir}
+Libs: @@libsflag@@${libdir} -lxentoollog
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 12/16] tools: provide pkg-config file for libxenstore
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenstore.pc file.
Signed-off-by: Juergen Gross
---
.gitignore| 1 +
tools/xenstore/Makefile | 21 +
tools/xenstore/xenstore.pc.in | 10 ++
3 files changed, 32 insertions(+)
create mode 100644 tools/xenstore/xenstore.pc.in
diff --git a/.gitignore b/.gitignore
index eb33788..b6859cf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -254,6 +254,7 @@ tools/xenstore/xenstore-control
tools/xenstore/xenstore-ls
tools/xenstore/xenstored
tools/xenstore/xenstored_test
+tools/xenstore/xenstore.pc
tools/xenstore/xs_tdb_dump
tools/xentrace/xentrace_setsize
tools/xentrace/tbctl
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index bdca108..c4f9cde 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -105,12 +105,32 @@ libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic
libxenstore.a: xs.o xs_lib.o
$(AR) rcs $@ $^
+PKG_CONFIG := xenstore.pc
+PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
+
+ifneq ($(CONFIG_LIBXC_MINIOS),y)
+PKG_CONFIG_INST := $(PKG_CONFIG)
+$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix)
+$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir)
+$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir)
+endif
+
+PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_XENSTORE)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
+
+$(LIBXENSTORE): $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
+
.PHONY: clean
clean:
rm -f *.a *.o *.opic *.so* xenstored_probes.h
rm -f xenstored xs_random xs_stress xs_crashme
rm -f xs_tdb_dump xenstore-control init-xenstore-domain
rm -f xenstore $(CLIENTS)
+ rm -f xenstore.pc
$(RM) $(DEPS)
.PHONY: distclean
@@ -150,6 +170,7 @@ endif
$(INSTALL_DATA) include/compat/xs_lib.h
$(DESTDIR)$(includedir)/xenstore-compat/xs_lib.h
ln -sf xenstore-compat/xs.h $(DESTDIR)$(includedir)/xs.h
ln -sf xenstore-compat/xs_lib.h $(DESTDIR)$(includedir)/xs_lib.h
+ $(INSTALL_DATA) xenstore.pc $(DESTDIR)$(PKG_INSTALLDIR)
.PHONY: clients-install
clients-install: clients
diff --git a/tools/xenstore/xenstore.pc.in b/tools/xenstore/xenstore.pc.in
new file mode 100644
index 000..45dc6b0
--- /dev/null
+++ b/tools/xenstore/xenstore.pc.in
@@ -0,0 +1,10 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xenstore
+Description: The Xenstore library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir} @@cflagslocal@@
+Libs: @@libsflag@@${libdir} -lxenstore
+Requires.private: xenevtchn,xencontrol,xengnttab
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 07/16] tools: provide pkg-config file for libxengnttab
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xengnttab.pc and a xengntshr.pc file.
Signed-off-by: Juergen Gross
---
.gitignore| 2 ++
tools/libs/gnttab/Makefile| 22 +-
tools/libs/gnttab/xengntshr.pc.in | 8
tools/libs/gnttab/xengnttab.pc.in | 10 ++
4 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644 tools/libs/gnttab/xengntshr.pc.in
create mode 100644 tools/libs/gnttab/xengnttab.pc.in
diff --git a/.gitignore b/.gitignore
index f4c58f2..3223f94 100644
--- a/.gitignore
+++ b/.gitignore
@@ -100,6 +100,8 @@ tools/libs/toollog/xentoollog.pc
tools/libs/evtchn/headers.chk
tools/libs/evtchn/xenevtchn.pc
tools/libs/gnttab/headers.chk
+tools/libs/gnttab/xengntshr.pc
+tools/libs/gnttab/xengnttab.pc
tools/libs/call/headers.chk
tools/libs/foreignmemory/headers.chk
tools/libs/devicemodel/headers.chk
diff --git a/tools/libs/gnttab/Makefile b/tools/libs/gnttab/Makefile
index 6a77f21..d4841c2 100644
--- a/tools/libs/gnttab/Makefile
+++ b/tools/libs/gnttab/Makefile
@@ -26,6 +26,23 @@ ifneq ($(nosharedlibs),y)
LIB += libxengnttab.so
endif
+PKG_CONFIG := xengnttab.pc xengntshr.pc
+PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
+
+ifneq ($(CONFIG_LIBXC_MINIOS),y)
+PKG_CONFIG_INST := $(PKG_CONFIG)
+$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix)
+$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir)
+$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir)
+endif
+
+PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENGNTTAB)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
+
.PHONY: all
all: build
@@ -34,7 +51,7 @@ build:
$(MAKE) libs
.PHONY: libs
-libs: headers.chk $(LIB)
+libs: headers.chk $(LIB) $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
headers.chk: $(wildcard include/*.h)
@@ -58,6 +75,8 @@ install: build
$(SYMLINK_SHLIB) libxengnttab.so.$(MAJOR).$(MINOR)
$(DESTDIR)$(libdir)/libxengnttab.so.$(MAJOR)
$(SYMLINK_SHLIB) libxengnttab.so.$(MAJOR)
$(DESTDIR)$(libdir)/libxengnttab.so
$(INSTALL_DATA) include/xengnttab.h $(DESTDIR)$(includedir)
+ $(INSTALL_DATA) xengnttab.pc $(DESTDIR)$(PKG_INSTALLDIR)
+ $(INSTALL_DATA) xengntshr.pc $(DESTDIR)$(PKG_INSTALLDIR)
.PHONY: TAGS
TAGS:
@@ -68,6 +87,7 @@ clean:
rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS)
rm -f libxengnttab.so.$(MAJOR).$(MINOR) libxengnttab.so.$(MAJOR)
rm -f headers.chk
+ rm -f xengnttab.pc xengntshr.pc
.PHONY: distclean
distclean: clean
diff --git a/tools/libs/gnttab/xengntshr.pc.in
b/tools/libs/gnttab/xengntshr.pc.in
new file mode 100644
index 000..1eb58c2
--- /dev/null
+++ b/tools/libs/gnttab/xengntshr.pc.in
@@ -0,0 +1,8 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xengntshr
+Description: The Xengntshr library for Xen hypervisor
+Version: @@version@@
+Requires: xengnttab
diff --git a/tools/libs/gnttab/xengnttab.pc.in
b/tools/libs/gnttab/xengnttab.pc.in
new file mode 100644
index 000..51aad22
--- /dev/null
+++ b/tools/libs/gnttab/xengnttab.pc.in
@@ -0,0 +1,10 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xengnttab
+Description: The Xengnttab library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir} @@cflagslocal@@
+Libs: @@libsflag@@${libdir} -lxengnttab
+Requires.private: xentoollog
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 08/16] tools: provide pkg-config file for libxencall
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xencall.pc file.
Signed-off-by: Juergen Gross
---
.gitignore| 1 +
tools/libs/call/Makefile | 21 -
tools/libs/call/xencall.pc.in | 10 ++
tools/libs/evtchn/Makefile| 1 -
tools/libs/evtchn/xenevtchn.pc.in | 2 +-
5 files changed, 32 insertions(+), 3 deletions(-)
create mode 100644 tools/libs/call/xencall.pc.in
diff --git a/.gitignore b/.gitignore
index 3223f94..86b003f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -103,6 +103,7 @@ tools/libs/gnttab/headers.chk
tools/libs/gnttab/xengntshr.pc
tools/libs/gnttab/xengnttab.pc
tools/libs/call/headers.chk
+tools/libs/call/xencall.pc
tools/libs/foreignmemory/headers.chk
tools/libs/devicemodel/headers.chk
tools/blktap2/daemon/blktapctrl
diff --git a/tools/libs/call/Makefile b/tools/libs/call/Makefile
index 9402ea5..30f8437 100644
--- a/tools/libs/call/Makefile
+++ b/tools/libs/call/Makefile
@@ -24,6 +24,23 @@ ifneq ($(nosharedlibs),y)
LIB += libxencall.so
endif
+PKG_CONFIG := xencall.pc
+PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
+
+ifneq ($(CONFIG_LIBXC_MINIOS),y)
+PKG_CONFIG_INST := $(PKG_CONFIG)
+$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix)
+$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir)
+$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir)
+endif
+
+PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENCALL)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
+
.PHONY: all
all: build
@@ -32,7 +49,7 @@ build:
$(MAKE) libs
.PHONY: libs
-libs: headers.chk $(LIB)
+libs: headers.chk $(LIB) $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
headers.chk: $(wildcard include/*.h)
@@ -56,6 +73,7 @@ install: build
$(SYMLINK_SHLIB) libxencall.so.$(MAJOR).$(MINOR)
$(DESTDIR)$(libdir)/libxencall.so.$(MAJOR)
$(SYMLINK_SHLIB) libxencall.so.$(MAJOR)
$(DESTDIR)$(libdir)/libxencall.so
$(INSTALL_DATA) include/xencall.h $(DESTDIR)$(includedir)
+ $(INSTALL_DATA) xencall.pc $(DESTDIR)$(PKG_INSTALLDIR)
.PHONY: TAGS
TAGS:
@@ -66,6 +84,7 @@ clean:
rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS)
rm -f libxencall.so.$(MAJOR).$(MINOR) libxencall.so.$(MAJOR)
rm -f headers.chk
+ rm -f xencall.pc
.PHONY: distclean
distclean: clean
diff --git a/tools/libs/call/xencall.pc.in b/tools/libs/call/xencall.pc.in
new file mode 100644
index 000..475c133
--- /dev/null
+++ b/tools/libs/call/xencall.pc.in
@@ -0,0 +1,10 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xencall
+Description: The Xencall library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir} @@cflagslocal@@
+Libs: @@libsflag@@${libdir} -lxencall
+Requires.private: xentoollog
diff --git a/tools/libs/evtchn/Makefile b/tools/libs/evtchn/Makefile
index 5da2693..cbd4219 100644
--- a/tools/libs/evtchn/Makefile
+++ b/tools/libs/evtchn/Makefile
@@ -39,7 +39,6 @@ PKG_CONFIG_LOCAL := $(foreach
pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENEVTCHN)/include
$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
-$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
.PHONY: all
all: build
diff --git a/tools/libs/evtchn/xenevtchn.pc.in
b/tools/libs/evtchn/xenevtchn.pc.in
index da8bf16..c74af1e 100644
--- a/tools/libs/evtchn/xenevtchn.pc.in
+++ b/tools/libs/evtchn/xenevtchn.pc.in
@@ -5,6 +5,6 @@ libdir=@@libdir@@
Name: Xenevtchn
Description: The Xenevtchn library for Xen hypervisor
Version: @@version@@
-Cflags: -I${includedir} @@cflagslocal@@
+Cflags: -I${includedir}
Libs: @@libsflag@@${libdir} -lxenevtchn
Requires.private: xentoollog
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 14/16] tools: provide pkg-config file for libxenvchan
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenvchan.pc file.
Signed-off-by: Juergen Gross
---
.gitignore| 1 +
tools/libvchan/Makefile | 21 -
tools/libvchan/xenvchan.pc.in | 10 ++
3 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 tools/libvchan/xenvchan.pc.in
diff --git a/.gitignore b/.gitignore
index fbea839..67d66e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -187,6 +187,7 @@ tools/include/xen/*
tools/include/xen-xsm/*
tools/include/xen-foreign/*.(c|h|size)
tools/include/xen-foreign/checker
+tools/libvchan/xenvchan.pc
tools/libxc/*.pc
tools/libxl/_libxl.api-for-check
tools/libxl/*.api-ok
diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile
index df70cf2..b816eb7 100644
--- a/tools/libvchan/Makefile
+++ b/tools/libvchan/Makefile
@@ -21,8 +21,25 @@ CFLAGS += -I../include -I.
io.o io.opic: CFLAGS += $(CFLAGS_libxenctrl) # for xen_mb et al
+PKG_CONFIG := xenvchan.pc
+PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
+
+ifneq ($(CONFIG_LIBXC_MINIOS),y)
+PKG_CONFIG_INST := $(PKG_CONFIG)
+$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix)
+$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir)
+$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir)
+endif
+
+PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBVCHAN)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
+
.PHONY: all
-all: libxenvchan.so vchan-node1 vchan-node2 libxenvchan.a
+all: libxenvchan.so vchan-node1 vchan-node2 libxenvchan.a $(PKG_CONFIG_INST)
$(PKG_CONFIG_LOCAL)
libxenvchan.so: libxenvchan.so.$(MAJOR)
ln -sf $< $@
@@ -51,10 +68,12 @@ install: all
ln -sf libxenvchan.so.$(MAJOR) $(DESTDIR)$(libdir)/libxenvchan.so
$(INSTALL_DATA) libxenvchan.h $(DESTDIR)$(includedir)
$(INSTALL_DATA) libxenvchan.a $(DESTDIR)$(libdir)
+ $(INSTALL_DATA) xenvchan.pc $(DESTDIR)$(PKG_INSTALLDIR)
.PHONY: clean
clean:
$(RM) -f *.o *.opic *.so* *.a vchan-node1 vchan-node2 $(DEPS)
+ $(RM) -f xenvchan.pc
distclean: clean
diff --git a/tools/libvchan/xenvchan.pc.in b/tools/libvchan/xenvchan.pc.in
new file mode 100644
index 000..605e42b
--- /dev/null
+++ b/tools/libvchan/xenvchan.pc.in
@@ -0,0 +1,10 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xenvchan
+Description: The Xenvchan library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir} @@cflagslocal@@
+Libs: @@libsflag@@${libdir} -lxenvchan
+Requires.private: xentoollog,xenstore,xengntshr,xenevtchn,xengnttab
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 11/16] tools: provide pkg-config file for libxenguest, update the one for libxenctrl
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenguest.pc file.
Update the xencontrol.pc file to reflect the dependencies of libxenctrl.
Signed-off-by: Juergen Gross
---
tools/libxc/Makefile | 6 --
tools/libxc/xencontrol.pc.in | 3 ++-
tools/libxc/xenguest.pc.in | 10 ++
3 files changed, 16 insertions(+), 3 deletions(-)
create mode 100644 tools/libxc/xenguest.pc.in
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b15736c..0732a9f 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -159,7 +159,7 @@ endif
$(CTRL_LIB_OBJS) $(GUEST_LIB_OBJS) \
$(CTRL_PIC_OBJS) $(GUEST_PIC_OBJS): xc_private.h
-PKG_CONFIG := xencontrol.pc
+PKG_CONFIG := xencontrol.pc xenguest.pc
PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
ifneq ($(CONFIG_LIBXC_MINIOS),y)
@@ -174,6 +174,7 @@ PKG_CONFIG_LOCAL := $(foreach
pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXC)/include
$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
.PHONY: all
all: build
@@ -201,6 +202,7 @@ install: build
$(SYMLINK_SHLIB) libxenguest.so.$(MAJOR)
$(DESTDIR)$(libdir)/libxenguest.so
$(INSTALL_DATA) include/xenguest.h $(DESTDIR)$(includedir)
$(INSTALL_DATA) xencontrol.pc $(DESTDIR)$(PKG_INSTALLDIR)
+ $(INSTALL_DATA) xenguest.pc $(DESTDIR)$(PKG_INSTALLDIR)
.PHONY: TAGS
TAGS:
@@ -210,7 +212,7 @@ TAGS:
clean:
rm -rf *.rpm $(LIB) *~ $(DEPS) \
_paths.h \
- xencontrol.pc \
+ xencontrol.pc xenguest.pc \
$(CTRL_LIB_OBJS) $(CTRL_PIC_OBJS) \
$(GUEST_LIB_OBJS) $(GUEST_PIC_OBJS)
diff --git a/tools/libxc/xencontrol.pc.in b/tools/libxc/xencontrol.pc.in
index 8651bca..fdc2530 100644
--- a/tools/libxc/xencontrol.pc.in
+++ b/tools/libxc/xencontrol.pc.in
@@ -5,5 +5,6 @@ libdir=@@libdir@@
Name: Xencontrol
Description: The Xencontrol library for Xen hypervisor
Version: @@version@@
-Cflags: -I${includedir}
+Cflags: -I${includedir} @@cflagslocal@@
Libs: @@libsflag@@${libdir} -lxenctrl
+Requires.private:
xenevtchn,xengnttab,xengntshr,xencall,xenforeignmemory,xendevicemodel,xentoollog
diff --git a/tools/libxc/xenguest.pc.in b/tools/libxc/xenguest.pc.in
new file mode 100644
index 000..225ac0b
--- /dev/null
+++ b/tools/libxc/xenguest.pc.in
@@ -0,0 +1,10 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xenguest
+Description: The Xenguest library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir}
+Libs: @@libsflag@@${libdir} -lxenguest
+Requires.private: xentoollog,xencall,xenforeignmemory,xenevtchn
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 04/16] tools: add support for additional items in .pc files for local builds
Some libraries require different compiler-flags when being used in a
local build compared to a build using installed libraries.
Reflect that by supporting local cflags variables in generated
pkg-config files. The local variants will be empty in the installed
pkg-config files.
The flags for the linker in the local variants will have to specify
the search patch for the library with "-Wl,-rpath-link=", while the
flags for the installed library will be "-L".
Add needed directory patterns.
Signed-off-by: Juergen Gross
---
tools/Rules.mk | 12 ++--
tools/libxc/xencontrol.pc.in | 2 +-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 9bb49af..8258749 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -254,10 +254,18 @@ $(PKG_CONFIG_DIR)/%.pc: %.pc.in Makefile
@sed -e 's!@@version@@!$(PKG_CONFIG_VERSION)!g' \
-e 's!@@prefix@@!$(PKG_CONFIG_PREFIX)!g' \
-e 's!@@incdir@@!$(PKG_CONFIG_INCDIR)!g' \
--e 's!@@libdir@@!$(PKG_CONFIG_LIBDIR)!g' < $< > $@
+-e 's!@@libdir@@!$(PKG_CONFIG_LIBDIR)!g' \
+-e 's!@@firmwaredir@@!$(XENFIRMWAREDIR)!g' \
+-e 's!@@libexecbin@@!$(LIBEXEC_BIN)!g' \
+-e 's!@@cflagslocal@@!$(PKG_CONFIG_CFLAGS_LOCAL)!g' \
+-e 's!@@libsflag@@!-Wl,-rpath-link=!g' < $< > $@
%.pc: %.pc.in Makefile
@sed -e 's!@@version@@!$(PKG_CONFIG_VERSION)!g' \
-e 's!@@prefix@@!$(PKG_CONFIG_PREFIX)!g' \
-e 's!@@incdir@@!$(PKG_CONFIG_INCDIR)!g' \
--e 's!@@libdir@@!$(PKG_CONFIG_LIBDIR)!g' < $< > $@
+-e 's!@@libdir@@!$(PKG_CONFIG_LIBDIR)!g' \
+-e 's!@@firmwaredir@@!$(XENFIRMWAREDIR)!g' \
+-e 's!@@libexecbin@@!$(LIBEXEC_BIN)!g' \
+-e 's!@@cflagslocal@@!!g' \
+-e 's!@@libsflag@@!-L!g' < $< > $@
diff --git a/tools/libxc/xencontrol.pc.in b/tools/libxc/xencontrol.pc.in
index 213206f..8651bca 100644
--- a/tools/libxc/xencontrol.pc.in
+++ b/tools/libxc/xencontrol.pc.in
@@ -6,4 +6,4 @@ Name: Xencontrol
Description: The Xencontrol library for Xen hypervisor
Version: @@version@@
Cflags: -I${includedir}
-Libs: -L${libdir} -lxenctrl
+Libs: @@libsflag@@${libdir} -lxenctrl
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 10/16] tools: provide pkg-config file for libxendevicemodel
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xendevicemodel.pc file.
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
tools/libs/devicemodel/Makefile | 21 -
tools/libs/devicemodel/xendevicemodel.pc.in | 10 ++
3 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 tools/libs/devicemodel/xendevicemodel.pc.in
diff --git a/.gitignore b/.gitignore
index 9a1ced7..eb33788 100644
--- a/.gitignore
+++ b/.gitignore
@@ -107,6 +107,7 @@ tools/libs/call/xencall.pc
tools/libs/foreignmemory/headers.chk
tools/libs/foreignmemory/xenforeignmemory.pc
tools/libs/devicemodel/headers.chk
+tools/libs/devicemodel/xendevicemodel.pc
tools/blktap2/daemon/blktapctrl
tools/blktap2/drivers/img2qcow
tools/blktap2/drivers/lock-util
diff --git a/tools/libs/devicemodel/Makefile b/tools/libs/devicemodel/Makefile
index 1803942..55626a5 100644
--- a/tools/libs/devicemodel/Makefile
+++ b/tools/libs/devicemodel/Makefile
@@ -25,6 +25,23 @@ ifneq ($(nosharedlibs),y)
LIB += libxendevicemodel.so
endif
+PKG_CONFIG := xendevicemodel.pc
+PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
+
+ifneq ($(CONFIG_LIBXC_MINIOS),y)
+PKG_CONFIG_INST := $(PKG_CONFIG)
+$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix)
+$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir)
+$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir)
+endif
+
+PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENDEVICEMODEL)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
+
.PHONY: all
all: build
@@ -33,7 +50,7 @@ build:
$(MAKE) libs
.PHONY: libs
-libs: headers.chk $(LIB)
+libs: headers.chk $(LIB) $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
headers.chk: $(wildcard include/*.h)
@@ -57,6 +74,7 @@ install: build
$(SYMLINK_SHLIB) libxendevicemodel.so.$(MAJOR).$(MINOR)
$(DESTDIR)$(libdir)/libxendevicemodel.so.$(MAJOR)
$(SYMLINK_SHLIB) libxendevicemodel.so.$(MAJOR)
$(DESTDIR)$(libdir)/libxendevicemodel.so
$(INSTALL_DATA) include/xendevicemodel.h $(DESTDIR)$(includedir)
+ $(INSTALL_DATA) xendevicemodel.pc $(DESTDIR)$(PKG_INSTALLDIR)
.PHONY: TAGS
TAGS:
@@ -67,6 +85,7 @@ clean:
rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS)
rm -f libxendevicemodel.so.$(MAJOR).$(MINOR)
libxendevicemodel.so.$(MAJOR)
rm -f headers.chk
+ rm -f xendevicemodel.pc
.PHONY: distclean
distclean: clean
diff --git a/tools/libs/devicemodel/xendevicemodel.pc.in
b/tools/libs/devicemodel/xendevicemodel.pc.in
new file mode 100644
index 000..ed08f83
--- /dev/null
+++ b/tools/libs/devicemodel/xendevicemodel.pc.in
@@ -0,0 +1,10 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xendevicemodel
+Description: The Xendevicemodel library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir} @@cflagslocal@@
+Libs: @@libsflag@@${libdir} -lxendevicemodel
+Requires.private: xentoollog,xencall
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 06/16] tools: provide pkg-config file for libxenevtchn
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenevtchn.pc file.
Signed-off-by: Juergen Gross
---
.gitignore| 1 +
tools/libs/evtchn/Makefile| 21 -
tools/libs/evtchn/xenevtchn.pc.in | 10 ++
3 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 tools/libs/evtchn/xenevtchn.pc.in
diff --git a/.gitignore b/.gitignore
index 374647c..f4c58f2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -98,6 +98,7 @@ config/Docs.mk
tools/libs/toollog/headers.chk
tools/libs/toollog/xentoollog.pc
tools/libs/evtchn/headers.chk
+tools/libs/evtchn/xenevtchn.pc
tools/libs/gnttab/headers.chk
tools/libs/call/headers.chk
tools/libs/foreignmemory/headers.chk
diff --git a/tools/libs/evtchn/Makefile b/tools/libs/evtchn/Makefile
index 9917864..5da2693 100644
--- a/tools/libs/evtchn/Makefile
+++ b/tools/libs/evtchn/Makefile
@@ -24,6 +24,23 @@ ifneq ($(nosharedlibs),y)
LIB += libxenevtchn.so
endif
+PKG_CONFIG := xenevtchn.pc
+PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
+
+ifneq ($(CONFIG_LIBXC_MINIOS),y)
+PKG_CONFIG_INST := $(PKG_CONFIG)
+$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix)
+$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir)
+$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir)
+endif
+
+PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENEVTCHN)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
+
.PHONY: all
all: build
@@ -32,7 +49,7 @@ build:
$(MAKE) libs
.PHONY: libs
-libs: headers.chk $(LIB)
+libs: headers.chk $(LIB) $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
headers.chk: $(wildcard include/*.h)
@@ -56,6 +73,7 @@ install: build
$(SYMLINK_SHLIB) libxenevtchn.so.$(MAJOR).$(MINOR)
$(DESTDIR)$(libdir)/libxenevtchn.so.$(MAJOR)
$(SYMLINK_SHLIB) libxenevtchn.so.$(MAJOR)
$(DESTDIR)$(libdir)/libxenevtchn.so
$(INSTALL_DATA) include/xenevtchn.h $(DESTDIR)$(includedir)
+ $(INSTALL_DATA) xenevtchn.pc $(DESTDIR)$(PKG_INSTALLDIR)
.PHONY: TAGS
TAGS:
@@ -66,6 +84,7 @@ clean:
rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS)
rm -f libxenevtchn.so.$(MAJOR).$(MINOR) libxenevtchn.so.$(MAJOR)
rm -f headers.chk
+ rm -f xenevtchn.pc
.PHONY: distclean
distclean: clean
diff --git a/tools/libs/evtchn/xenevtchn.pc.in
b/tools/libs/evtchn/xenevtchn.pc.in
new file mode 100644
index 000..da8bf16
--- /dev/null
+++ b/tools/libs/evtchn/xenevtchn.pc.in
@@ -0,0 +1,10 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xenevtchn
+Description: The Xenevtchn library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir} @@cflagslocal@@
+Libs: @@libsflag@@${libdir} -lxenevtchn
+Requires.private: xentoollog
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 13/16] tools: provide pkg-config file for libxenstat
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenstat.pc file.
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
tools/xenstat/libxenstat/Makefile | 20 +++-
tools/xenstat/libxenstat/xenstat.pc.in | 10 ++
3 files changed, 30 insertions(+), 1 deletion(-)
create mode 100644 tools/xenstat/libxenstat/xenstat.pc.in
diff --git a/.gitignore b/.gitignore
index b6859cf..fbea839 100644
--- a/.gitignore
+++ b/.gitignore
@@ -241,6 +241,7 @@ tools/xenmon/xentrace_setmask
tools/xenmon/xenbaked
tools/xenpaging/xenpaging
tools/xenpmd/xenpmd
+tools/xenstat/libxenstat/xenstat.pc
tools/xenstat/libxenstat/src/_paths.h
tools/xenstat/xentop/xentop
tools/xenstore/xenstore
diff --git a/tools/xenstat/libxenstat/Makefile
b/tools/xenstat/libxenstat/Makefile
index 213d998..85cec63 100644
--- a/tools/xenstat/libxenstat/Makefile
+++ b/tools/xenstat/libxenstat/Makefile
@@ -37,8 +37,24 @@ CFLAGS+=-Isrc $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore)
$(CFLAGS_xeninclude) -i
LDLIBS-y = $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl)
LDLIBS-$(CONFIG_SunOS) += -lkstat
+PKG_CONFIG := xenstat.pc
+PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
+
+ifneq ($(CONFIG_LIBXC_MINIOS),y)
+PKG_CONFIG_INST := $(PKG_CONFIG)
+$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix)
+$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir)
+$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir)
+endif
+
+PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENSTAT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+
.PHONY: all
-all: $(LIB) $(SHLIB) $(SHLIB_LINKS)
+all: $(LIB) $(SHLIB) $(SHLIB_LINKS) $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
$(OBJECTS-y): src/_paths.h
@@ -63,6 +79,7 @@ install: all
$(INSTALL_PROG) src/libxenstat.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)
ln -sf libxenstat.so.$(MAJOR).$(MINOR)
$(DESTDIR)$(libdir)/libxenstat.so.$(MAJOR)
ln -sf libxenstat.so.$(MAJOR) $(DESTDIR)$(libdir)/libxenstat.so
+ $(INSTALL_DATA) xenstat.pc $(DESTDIR)$(PKG_INSTALLDIR)
PYLIB=bindings/swig/python/_xenstat.so
PYMOD=bindings/swig/python/xenstat.py
@@ -138,6 +155,7 @@ endif
clean:
rm -f $(LIB) $(SHLIB) $(SHLIB_LINKS) $(OBJECTS-y) \
$(BINDINGS) $(BINDINGSRC) $(DEPS) src/_paths.h
+ rm -f xenstat.pc
.PHONY: distclean
distclean: clean
diff --git a/tools/xenstat/libxenstat/xenstat.pc.in
b/tools/xenstat/libxenstat/xenstat.pc.in
new file mode 100644
index 000..ad00577
--- /dev/null
+++ b/tools/xenstat/libxenstat/xenstat.pc.in
@@ -0,0 +1,10 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xenstat
+Description: The Xenstat library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir}
+Libs: @@libsflag@@${libdir} -lxenstat
+Requires.private: xencontrol,xenstore
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 03/16] tools, stubdom: set PKG_CONFIG_DIR in main Makefiles
Instead of setting the PKG_CONFIG_DIR make variable in each library Makefile do it in tools/Makefile and stubdom/Makefile globally. Signed-off-by: Juergen Gross --- stubdom/Makefile | 1 + tools/Makefile | 3 +++ tools/libxc/Makefile | 1 - 3 files changed, 4 insertions(+), 1 deletion(-) diff --git a/stubdom/Makefile b/stubdom/Makefile index c6458e8..54a2bdd 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -3,6 +3,7 @@ MINI_OS = $(XEN_ROOT)/extras/mini-os export XEN_ROOT export XEN_OS=MiniOS +export PKG_CONFIG_DIR = $(CURDIR)/pkg-config # Remove flags which are meant for tools, e.g. "-m64" export EXTRA_CFLAGS_XEN_TOOLS= diff --git a/tools/Makefile b/tools/Makefile index 85e5ce9..828ee34 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -1,4 +1,7 @@ XEN_ROOT = $(CURDIR)/.. + +export PKG_CONFIG_DIR = $(CURDIR)/pkg-config + include $(XEN_ROOT)/tools/Rules.mk SUBDIRS-y := diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile index a161ba7..b15736c 100644 --- a/tools/libxc/Makefile +++ b/tools/libxc/Makefile @@ -1,5 +1,4 @@ XEN_ROOT = $(CURDIR)/../.. -PKG_CONFIG_DIR = ../pkg-config include $(XEN_ROOT)/tools/Rules.mk MAJOR= 4.9 -- 2.10.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 00/16] tools: provide pkg-config files for all libs
To help consumers of the Xen libraries (e.g. qemu) to use correct flags when building provide pkg-config files for all libraries of Xen. The first 2 patches correct some flags used by the Xen internal build system. The build process wasn't producing wrong results, but this was just pure luck as no flags were missing when building some libraries, but they came partially from other variables then they were meant to. Patches 3 and 4 set the stage for generating the pkg-config files. The rest of the patches are one for each directory where at least one library is being built. Especially patch 16 is modifying the way the already existing pkg-config files for libxenlight and libxlutil are being built to fit into the new scheme. Even if not necessary right now I have added stubdom support for all libraries, not only the ones which are really used in stubdom environment. Juergen Gross (16): tools: fix typo in tools/Rules.mk tools: add missing library flag definitions tools,stubdom: set PKG_CONFIG_DIR in main Makefiles tools: add support for additional items in .pc files for local builds tools: provide pkg-config file for libxentoollog tools: provide pkg-config file for libxenevtchn tools: provide pkg-config file for libxengnttab tools: provide pkg-config file for libxencall tools: provide pkg-config file for libxenforeignmemory tools: provide pkg-config file for libxendevicemodel tools: provide pkg-config file for libxenguest, update the one for libxenctrl tools: provide pkg-config file for libxenstore tools: provide pkg-config file for libxenstat tools: provide pkg-config file for libxenvchan tools: provide pkg-config file for libxenblktapctl tools: adapt xenlight.pc and xlutil.pc to new pkg-config scheme .gitignore | 12 ++- stubdom/Makefile| 1 + tools/Makefile | 3 ++ tools/Rules.mk | 43 - tools/blktap2/control/Makefile | 23 +++-- tools/blktap2/control/xenblktapctl.pc.in| 9 ++ tools/configure | 4 +-- tools/configure.ac | 2 -- tools/libs/call/Makefile| 21 +++- tools/libs/call/xencall.pc.in | 10 ++ tools/libs/devicemodel/Makefile | 21 +++- tools/libs/devicemodel/xendevicemodel.pc.in | 10 ++ tools/libs/evtchn/Makefile | 20 +++- tools/libs/evtchn/xenevtchn.pc.in | 10 ++ tools/libs/foreignmemory/Makefile | 21 +++- tools/libs/foreignmemory/xenforeignmemory.pc.in | 10 ++ tools/libs/gnttab/Makefile | 22 - tools/libs/gnttab/xengntshr.pc.in | 8 + tools/libs/gnttab/xengnttab.pc.in | 10 ++ tools/libs/toollog/Makefile | 20 +++- tools/libs/toollog/xentoollog.pc.in | 9 ++ tools/libvchan/Makefile | 21 +++- tools/libvchan/xenvchan.pc.in | 10 ++ tools/libxc/Makefile| 7 ++-- tools/libxc/xencontrol.pc.in| 5 +-- tools/libxc/xenguest.pc.in | 10 ++ tools/libxl/Makefile| 25 +++--- tools/libxl/xenlight.pc.in | 12 +++ tools/libxl/xenlight.pc.in.in | 11 --- tools/libxl/xlutil.pc.in| 10 ++ tools/libxl/xlutil.pc.in.in | 9 -- tools/xenstat/libxenstat/Makefile | 20 +++- tools/xenstat/libxenstat/xenstat.pc.in | 10 ++ tools/xenstore/Makefile | 21 tools/xenstore/xenstore.pc.in | 10 ++ 35 files changed, 408 insertions(+), 62 deletions(-) create mode 100644 tools/blktap2/control/xenblktapctl.pc.in create mode 100644 tools/libs/call/xencall.pc.in create mode 100644 tools/libs/devicemodel/xendevicemodel.pc.in create mode 100644 tools/libs/evtchn/xenevtchn.pc.in create mode 100644 tools/libs/foreignmemory/xenforeignmemory.pc.in create mode 100644 tools/libs/gnttab/xengntshr.pc.in create mode 100644 tools/libs/gnttab/xengnttab.pc.in create mode 100644 tools/libs/toollog/xentoollog.pc.in create mode 100644 tools/libvchan/xenvchan.pc.in create mode 100644 tools/libxc/xenguest.pc.in create mode 100644 tools/libxl/xenlight.pc.in delete mode 100644 tools/libxl/xenlight.pc.in.in create mode 100644 tools/libxl/xlutil.pc.in delete mode 100644 tools/libxl/xlutil.pc.in.in create mode 100644 tools/xenstat/libxenstat/xenstat.pc.in create mode 100644 tools/xenstore/xenstore.pc.in -- 2.10.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org htt
[Xen-devel] [PATCH 02/16] tools: add missing library flag definitions
LDLIBS_* and SHLIB_* settings in tools/Rules.mk are sometimes missing some SHDEPS_* added to them. Add the missing flags, even if sometimes being empty. Signed-off-by: Juergen Gross --- tools/Rules.mk | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/tools/Rules.mk b/tools/Rules.mk index 835525a..9bb49af 100644 --- a/tools/Rules.mk +++ b/tools/Rules.mk @@ -94,13 +94,13 @@ endif CFLAGS_libxentoollog = -I$(XEN_LIBXENTOOLLOG)/include $(CFLAGS_xeninclude) SHDEPS_libxentoollog = -LDLIBS_libxentoollog = $(XEN_LIBXENTOOLLOG)/libxentoollog$(libextension) -SHLIB_libxentoollog = -Wl,-rpath-link=$(XEN_LIBXENTOOLLOG) +LDLIBS_libxentoollog = $(SHDEPS_libxentoollog) $(XEN_LIBXENTOOLLOG)/libxentoollog$(libextension) +SHLIB_libxentoollog = $(SHDEPS_libxentoollog) -Wl,-rpath-link=$(XEN_LIBXENTOOLLOG) CFLAGS_libxenevtchn = -I$(XEN_LIBXENEVTCHN)/include $(CFLAGS_xeninclude) SHDEPS_libxenevtchn = -LDLIBS_libxenevtchn = $(XEN_LIBXENEVTCHN)/libxenevtchn$(libextension) -SHLIB_libxenevtchn = -Wl,-rpath-link=$(XEN_LIBXENEVTCHN) +LDLIBS_libxenevtchn = $(SHDEPS_libxenevtchn) $(XEN_LIBXENEVTCHN)/libxenevtchn$(libextension) +SHLIB_libxenevtchn = $(SHDEPS_libxenevtchn) -Wl,-rpath-link=$(XEN_LIBXENEVTCHN) CFLAGS_libxengnttab = -I$(XEN_LIBXENGNTTAB)/include $(CFLAGS_xeninclude) SHDEPS_libxengnttab = $(SHLIB_libxentoollog) @@ -109,21 +109,24 @@ SHLIB_libxengnttab = $(SHDEPS_libxengnttab) -Wl,-rpath-link=$(XEN_LIBXENGNTTAB) # xengntshr_* interfaces are actually part of libxengnttab.so CFLAGS_libxengntshr = -I$(XEN_LIBXENGNTTAB)/include $(CFLAGS_xeninclude) -LDLIBS_libxengntshr = $(XEN_LIBXENGNTTAB)/libxengnttab$(libextension) -SHLIB_libxengntshr = -Wl,-rpath-link=$(XEN_LIBXENGNTTAB) +SHDEPS_libxengntshr = $(SHDEPS_libxengnttab) +LDLIBS_libxengntshr = $(SHDEPS_libxengntshr) $(XEN_LIBXENGNTTAB)/libxengnttab$(libextension) +SHLIB_libxengntshr = $(SHDEPS_libxengntshr) -Wl,-rpath-link=$(XEN_LIBXENGNTTAB) CFLAGS_libxencall = -I$(XEN_LIBXENCALL)/include $(CFLAGS_xeninclude) -LDLIBS_libxencall = $(XEN_LIBXENCALL)/libxencall$(libextension) -SHLIB_libxencall = -Wl,-rpath-link=$(XEN_LIBXENCALL) +SHDEPS_libxencall = +LDLIBS_libxencall = $(SHDEPS_libxencall) $(XEN_LIBXENCALL)/libxencall$(libextension) +SHLIB_libxencall = $(SHDEPS_libxencall) -Wl,-rpath-link=$(XEN_LIBXENCALL) CFLAGS_libxenforeignmemory = -I$(XEN_LIBXENFOREIGNMEMORY)/include $(CFLAGS_xeninclude) -LDLIBS_libxenforeignmemory = $(XEN_LIBXENFOREIGNMEMORY)/libxenforeignmemory$(libextension) -SHLIB_libxenforeignmemory = -Wl,-rpath-link=$(XEN_LIBXENFOREIGNMEMORY) +SHDEPS_libxenforeignmemory = +LDLIBS_libxenforeignmemory = $(SHDEPS_libxenforeignmemory) $(XEN_LIBXENFOREIGNMEMORY)/libxenforeignmemory$(libextension) +SHLIB_libxenforeignmemory = $(SHDEPS_libxenforeignmemory) -Wl,-rpath-link=$(XEN_LIBXENFOREIGNMEMORY) CFLAGS_libxendevicemodel = -I$(XEN_LIBXENDEVICEMODEL)/include $(CFLAGS_xeninclude) SHDEPS_libxendevicemodel = $(SHLIB_libxentoollog) $(SHLIB_xencall) -LDLIBS_libxendevicemodel = $(XEN_LIBXENDEVICEMODEL)/libxendevicemodel$(libextension) -SHLIB_libxendevicemodel = -Wl,-rpath-link=$(XEN_LIBXENDEVICEMODEL) +LDLIBS_libxendevicemodel = $(SHDEPS_libxendevicemodel) $(XEN_LIBXENDEVICEMODEL)/libxendevicemodel$(libextension) +SHLIB_libxendevicemodel = $(SHDEPS_libxendevicemodel) -Wl,-rpath-link=$(XEN_LIBXENDEVICEMODEL) # code which compiles against libxenctrl get __XEN_TOOLS__ and # therefore sees the unstable hypercall interfaces. -- 2.10.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 09/16] tools: provide pkg-config file for libxenforeignmemory
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenforeignmemory.pc file.
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
tools/libs/foreignmemory/Makefile | 21 -
tools/libs/foreignmemory/xenforeignmemory.pc.in | 10 ++
3 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 tools/libs/foreignmemory/xenforeignmemory.pc.in
diff --git a/.gitignore b/.gitignore
index 86b003f..9a1ced7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -105,6 +105,7 @@ tools/libs/gnttab/xengnttab.pc
tools/libs/call/headers.chk
tools/libs/call/xencall.pc
tools/libs/foreignmemory/headers.chk
+tools/libs/foreignmemory/xenforeignmemory.pc
tools/libs/devicemodel/headers.chk
tools/blktap2/daemon/blktapctrl
tools/blktap2/drivers/img2qcow
diff --git a/tools/libs/foreignmemory/Makefile
b/tools/libs/foreignmemory/Makefile
index f062f45..55677e8 100644
--- a/tools/libs/foreignmemory/Makefile
+++ b/tools/libs/foreignmemory/Makefile
@@ -24,6 +24,23 @@ ifneq ($(nosharedlibs),y)
LIB += libxenforeignmemory.so
endif
+PKG_CONFIG := xenforeignmemory.pc
+PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
+
+ifneq ($(CONFIG_LIBXC_MINIOS),y)
+PKG_CONFIG_INST := $(PKG_CONFIG)
+$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix)
+$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir)
+$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir)
+endif
+
+PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_LIBXENFOREIGNMEMORY)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
+
.PHONY: all
all: build
@@ -32,7 +49,7 @@ build:
$(MAKE) libs
.PHONY: libs
-libs: headers.chk $(LIB)
+libs: headers.chk $(LIB) $(PKG_CONFIG_INST) $(PKG_CONFIG_LOCAL)
headers.chk: $(wildcard include/*.h)
@@ -56,6 +73,7 @@ install: build
$(SYMLINK_SHLIB) libxenforeignmemory.so.$(MAJOR).$(MINOR)
$(DESTDIR)$(libdir)/libxenforeignmemory.so.$(MAJOR)
$(SYMLINK_SHLIB) libxenforeignmemory.so.$(MAJOR)
$(DESTDIR)$(libdir)/libxenforeignmemory.so
$(INSTALL_DATA) include/xenforeignmemory.h $(DESTDIR)$(includedir)
+ $(INSTALL_DATA) xenforeignmemory.pc $(DESTDIR)$(PKG_INSTALLDIR)
.PHONY: TAGS
TAGS:
@@ -66,6 +84,7 @@ clean:
rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS)
rm -f libxenforeignmemory.so.$(MAJOR).$(MINOR)
libxenforeignmemory.so.$(MAJOR)
rm -f headers.chk
+ rm -f xenforeignmemory.pc
.PHONY: distclean
distclean: clean
diff --git a/tools/libs/foreignmemory/xenforeignmemory.pc.in
b/tools/libs/foreignmemory/xenforeignmemory.pc.in
new file mode 100644
index 000..63432dc
--- /dev/null
+++ b/tools/libs/foreignmemory/xenforeignmemory.pc.in
@@ -0,0 +1,10 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xenforeignmemory
+Description: The Xenforeignmemory library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir} @@cflagslocal@@
+Libs: @@libsflag@@${libdir} -lxenforeignmemory
+Requires.private: xentoollog
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 15/16] tools: provide pkg-config file for libxenblktapctl
In order to be able to use pkg-config for obtaining linker- and
compiler-flags provide a xenblktapctl.pc file.
Signed-off-by: Juergen Gross
---
.gitignore | 1 +
tools/blktap2/control/Makefile | 23 +--
tools/blktap2/control/xenblktapctl.pc.in | 9 +
3 files changed, 31 insertions(+), 2 deletions(-)
create mode 100644 tools/blktap2/control/xenblktapctl.pc.in
diff --git a/.gitignore b/.gitignore
index 67d66e2..8606ba1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -108,6 +108,7 @@ tools/libs/foreignmemory/headers.chk
tools/libs/foreignmemory/xenforeignmemory.pc
tools/libs/devicemodel/headers.chk
tools/libs/devicemodel/xendevicemodel.pc
+tools/blktap2/control/xenblktapctl.pc
tools/blktap2/daemon/blktapctrl
tools/blktap2/drivers/img2qcow
tools/blktap2/drivers/lock-util
diff --git a/tools/blktap2/control/Makefile b/tools/blktap2/control/Makefile
index 767f52a..0d731f7 100644
--- a/tools/blktap2/control/Makefile
+++ b/tools/blktap2/control/Makefile
@@ -41,9 +41,26 @@ LIB_STATIC = $(LIBNAME).a
LIB_SHARED = $(LIBSONAME).$(MINOR)
IBIN = tap-ctl
+PKG_CONFIG := xenblktapctl.pc
+PKG_CONFIG_VERSION := $(MAJOR).$(MINOR)
+
+ifneq ($(CONFIG_LIBXC_MINIOS),y)
+PKG_CONFIG_INST := $(PKG_CONFIG)
+$(PKG_CONFIG_INST): PKG_CONFIG_PREFIX = $(prefix)
+$(PKG_CONFIG_INST): PKG_CONFIG_INCDIR = $(includedir)
+$(PKG_CONFIG_INST): PKG_CONFIG_LIBDIR = $(libdir)
+endif
+
+PKG_CONFIG_LOCAL := $(foreach pc,$(PKG_CONFIG),$(PKG_CONFIG_DIR)/$(pc))
+
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_PREFIX = $(XEN_ROOT)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_INCDIR = $(XEN_BLKTAP2)/include
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_LIBDIR = $(CURDIR)
+$(PKG_CONFIG_LOCAL): PKG_CONFIG_CFLAGS_LOCAL = $(CFLAGS_xeninclude)
$(CFLAGS_libxenctrl)
+
all: build
-build: $(IBIN) $(LIB_STATIC) $(LIB_SHARED)
+build: $(IBIN) $(LIB_STATIC) $(LIB_SHARED) $(PKG_CONFIG_INST)
$(PKG_CONFIG_LOCAL)
$(LIBNAME).so: $(LIBSONAME)
ln -sf $< $@
@@ -60,18 +77,20 @@ $(LIB_STATIC): $(CTL_OBJS)
$(LIB_SHARED): $(CTL_PICS)
$(CC) $(LDFLAGS) -fPIC -Wl,$(SONAME_LDFLAG) -Wl,$(LIBSONAME)
$(SHLIB_LDFLAGS) -rdynamic $^ -o $@ $(APPEND_LDFLAGS)
-install: $(IBIN) $(LIB_STATIC) $(LIB_SHARED)
+install: build
$(INSTALL_DIR) -p $(DESTDIR)$(sbindir)
$(INSTALL_PROG) $(IBIN) $(DESTDIR)$(sbindir)
$(INSTALL_DATA) $(LIB_STATIC) $(DESTDIR)$(libdir)
$(INSTALL_PROG) $(LIB_SHARED) $(DESTDIR)$(libdir)
ln -sf $(LIBSONAME) $(DESTDIR)$(libdir)/$(LIBNAME).so
ln -sf $(LIB_SHARED) $(DESTDIR)$(libdir)/$(LIBSONAME)
+ $(INSTALL_DATA) xenblktapctl.pc $(DESTDIR)$(PKG_INSTALLDIR)
clean:
rm -f $(OBJS) $(PICS) $(DEPS) $(IBIN) $(LIB_STATIC) $(LIB_SHARED)
rm -f $(LIBNAME).so $(LIBSONAME)
rm -f *~
+ rm -f xenblktapctl.pc
distclean: clean
diff --git a/tools/blktap2/control/xenblktapctl.pc.in
b/tools/blktap2/control/xenblktapctl.pc.in
new file mode 100644
index 000..81d2747
--- /dev/null
+++ b/tools/blktap2/control/xenblktapctl.pc.in
@@ -0,0 +1,9 @@
+prefix=@@prefix@@
+includedir=@@incdir@@
+libdir=@@libdir@@
+
+Name: Xenblktapctl
+Description: The Xenblktapctl library for Xen hypervisor
+Version: @@version@@
+Cflags: -I${includedir} @@cflagslocal@@
+Libs: @@libsflag@@${libdir} -lxenblktapctl
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 01/16] tools: fix typo in tools/Rules.mk
Commit 78fb69ad9 ("tools/Rules.mk: Properly handle libraries with
recursive dependencies.") introduced a copy and paste error in
tools/Rules.mk:
LDLIBS_libxenstore and SHLIB_libxenstore don't use SHDEPS_libxenstore
but SHDEPS_libxenguest. This will add a superfluous dependency of
libxenstore on libxenevtchn.
Correct this bug.
Signed-off-by: Juergen Gross
---
tools/Rules.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/Rules.mk b/tools/Rules.mk
index e676c6b..835525a 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -139,8 +139,8 @@ SHLIB_libxenguest = $(SHDEPS_libxenguest)
-Wl,-rpath-link=$(XEN_LIBXC)
CFLAGS_libxenstore = -I$(XEN_XENSTORE)/include $(CFLAGS_xeninclude)
SHDEPS_libxenstore =
-LDLIBS_libxenstore = $(SHDEPS_libxenguest)
$(XEN_XENSTORE)/libxenstore$(libextension)
-SHLIB_libxenstore = $(SHDEPS_libxenguest) -Wl,-rpath-link=$(XEN_XENSTORE)
+LDLIBS_libxenstore = $(SHDEPS_libxenstore)
$(XEN_XENSTORE)/libxenstore$(libextension)
+SHLIB_libxenstore = $(SHDEPS_libxenstore) -Wl,-rpath-link=$(XEN_XENSTORE)
CFLAGS_libxenstat = -I$(XEN_LIBXENSTAT)
SHDEPS_libxenstat = $(SHLIB_libxenctrl) $(SHLIB_libxenstore)
--
2.10.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 01/21] x86/xen: separate PV and HVM hypervisors
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> As a preparation to splitting the code we need to untangle it:
>
> x86_hyper_xen -> x86_hyper_xen_hvm and x86_hyper_xen_pv
> xen_platform() -> xen_platform_hvm() and xen_platform_pv()
> xen_cpu_up_prepare() -> xen_cpu_up_prepare_pv() and xen_cpu_up_prepare_hvm()
> xen_cpu_dead() -> xen_cpu_dead_pv() and xen_cpu_dead_pv_hvm()
>
> Add two parameters to xen_cpuhp_setup() to pass proper cpu_up_prepare and
> cpu_dead hooks. xen_set_cpu_features() is now PV-only so the redundant
> xen_pv_domain() check can be dropped.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/include/asm/hypervisor.h | 3 +-
> arch/x86/kernel/cpu/hypervisor.c | 3 +-
> arch/x86/xen/enlighten.c | 113
> +-
> 3 files changed, 78 insertions(+), 41 deletions(-)
>
> diff --git a/arch/x86/include/asm/hypervisor.h
> b/arch/x86/include/asm/hypervisor.h
> index 67942b6..6f7545c6 100644
> --- a/arch/x86/include/asm/hypervisor.h
> +++ b/arch/x86/include/asm/hypervisor.h
> @@ -53,7 +53,8 @@ extern const struct hypervisor_x86 *x86_hyper;
> /* Recognized hypervisors */
> extern const struct hypervisor_x86 x86_hyper_vmware;
> extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
> -extern const struct hypervisor_x86 x86_hyper_xen;
> +extern const struct hypervisor_x86 x86_hyper_xen_pv;
> +extern const struct hypervisor_x86 x86_hyper_xen_hvm;
> extern const struct hypervisor_x86 x86_hyper_kvm;
>
> extern void init_hypervisor(struct cpuinfo_x86 *c);
> diff --git a/arch/x86/kernel/cpu/hypervisor.c
> b/arch/x86/kernel/cpu/hypervisor.c
> index 35691a6..a77f18d 100644
> --- a/arch/x86/kernel/cpu/hypervisor.c
> +++ b/arch/x86/kernel/cpu/hypervisor.c
> @@ -29,7 +29,8 @@
> static const __initconst struct hypervisor_x86 * const hypervisors[] =
> {
> #ifdef CONFIG_XEN
> - &x86_hyper_xen,
> + &x86_hyper_xen_pv,
> + &x86_hyper_xen_hvm,
> #endif
> &x86_hyper_vmware,
> &x86_hyper_ms_hyperv,
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index ec1d5c4..4c1a582 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -139,9 +139,11 @@ void *xen_initial_gdt;
>
> RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
>
> -static int xen_cpu_up_prepare(unsigned int cpu);
> +static int xen_cpu_up_prepare_pv(unsigned int cpu);
> +static int xen_cpu_up_prepare_hvm(unsigned int cpu);
> static int xen_cpu_up_online(unsigned int cpu);
> -static int xen_cpu_dead(unsigned int cpu);
> +static int xen_cpu_dead_pv(unsigned int cpu);
> +static int xen_cpu_dead_hvm(unsigned int cpu);
>
> /*
> * Point at some empty memory to start with. We map the real shared_info
> @@ -1447,13 +1449,14 @@ static void __init xen_dom0_set_legacy_features(void)
> x86_platform.legacy.rtc = 1;
> }
>
> -static int xen_cpuhp_setup(void)
> +static int xen_cpuhp_setup(int (*cpu_up_prepare_cb)(unsigned int),
> +int (*cpu_dead_cb)(unsigned int))
> {
> int rc;
>
> rc = cpuhp_setup_state_nocalls(CPUHP_XEN_PREPARE,
> "x86/xen/hvm_guest:prepare",
> -xen_cpu_up_prepare, xen_cpu_dead);
> +cpu_up_prepare_cb, cpu_dead_cb);
> if (rc >= 0) {
> rc = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
> "x86/xen/hvm_guest:online",
> @@ -1559,7 +1562,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
> possible map and a non-dummy shared_info. */
> per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
>
> - WARN_ON(xen_cpuhp_setup());
> + WARN_ON(xen_cpuhp_setup(xen_cpu_up_prepare_pv, xen_cpu_dead_pv));
>
> local_irq_disable();
> early_boot_irqs_disabled = true;
> @@ -1840,28 +1843,41 @@ static void __init init_hvm_pv_info(void)
> }
> #endif
>
> -static int xen_cpu_up_prepare(unsigned int cpu)
> +static int xen_cpu_up_prepare_pv(unsigned int cpu)
> {
> int rc;
>
> - if (xen_hvm_domain()) {
> - /*
> - * This can happen if CPU was offlined earlier and
> - * offlining timed out in common_cpu_die().
> - */
> - if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
> - xen_smp_intr_free(cpu);
> - xen_uninit_lock_cpu(cpu);
> - }
> + xen_setup_timer(cpu);
>
> - if (cpu_acpi_id(cpu) != U32_MAX)
> - per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
> - else
> - per_cpu(xen_vcpu_id, cpu) = cpu;
> - xen_vcpu_setup(cpu);
> + rc = xen_smp_intr_init(cpu);
> + if (rc) {
> + WARN(1, "xen_smp_intr_init() for CPU %d failed: %d\n",
> + cpu, rc);
> + return rc;
> + }
> + return 0;
> +}
> +
> +static int xen_cpu_up_prepare_hvm(unsigned
Re: [Xen-devel] [PATCH v2 02/21] x86/xen: globalize have_vcpu_info_placement
On 02/03/17 18:53, Vitaly Kuznetsov wrote: > have_vcpu_info_placement applies to both PV and HVM and as we're going > to split the code we need to make it global. > > Rename to xen_have_vcpu_info_placement. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 04/24] x86: refactor psr: implement CPU init and free flow.
>>> On 15.02.17 at 09:49, wrote:
> This patch implements the CPU init and free flow including L3 CAT
> initialization and feature list free.
I think from the final-effect-of-the-patch point of view the L3 CAT
aspect is more relevant, so that's what should appear in the title.
> @@ -136,11 +140,87 @@ struct psr_assoc {
>
> struct psr_cmt *__read_mostly psr_cmt;
>
> +static struct psr_socket_info *__read_mostly socket_info;
> +
> static unsigned int opt_psr;
> static unsigned int __initdata opt_rmid_max = 255;
> +static unsigned int __read_mostly opt_cos_max = MAX_COS_REG_CNT;
> static uint64_t rmid_mask;
> static DEFINE_PER_CPU(struct psr_assoc, psr_assoc);
>
> +/*
> + * Declare global feature list entry for every feature to facilitate the
> + * feature list creation. It will be allocated in psr_cpu_prepare() and
> + * inserted into feature list in cpu_init_work(). It is protected by
> + * cpu_add_remove_lock spinlock.
> + */
> +static struct feat_node *feat_l3_cat;
The comment is misleading imo: The only relevant aspect here is that
of when the allocation would need to happen vs. when it actually
happens (because putting it where we'd like it to be is not easily
possible). There's nothing list related here. I'd recommend simply
saying that we need a place to transiently store a spare node.
> +/* Common functions. */
> +static void free_feature(struct psr_socket_info *info)
> +{
> +struct feat_node *feat, *next;
> +
> +if ( !info )
> +return;
> +
> +/*
> + * Free resources of features. But we do not free global feature list
> + * entry, like feat_l3_cat. Although it may cause a few memory leak,
> + * it is OK simplify things.
> + */
> +list_for_each_entry_safe(feat, next, &info->feat_list, list)
> +{
> +if ( !feat )
> +return;
How would that happen? But well, this is going to go away anyway
with the move from list to array.
> @@ -335,18 +418,104 @@ void psr_domain_free(struct domain *d)
> psr_free_rmid(d);
> }
>
> -static int psr_cpu_prepare(unsigned int cpu)
> +static void cpu_init_work(void)
> +{
> +struct psr_socket_info *info;
> +unsigned int socket;
> +unsigned int cpu = smp_processor_id();
> +struct feat_node *feat;
> +struct cpuid_leaf regs = { .a = 0, .b = 0, .c = 0, .d = 0 };
I don't see you needing an initializer here at all, but if you really
want one for some reason, the same effect can be had with just
{}.
> +if ( !cpu_has(¤t_cpu_data, X86_FEATURE_PQE) )
Do you really mean to not universally check the global (boot CPU)
flag? I.e. possibly differing behavior on different CPUs?
> +return;
> +else if ( current_cpu_data.cpuid_level < PSR_CPUID_LEVEL_CAT )
Pointless "else".
> +{
> +__clear_bit(X86_FEATURE_PQE, current_cpu_data.x86_capability);
setup_clear_cpu_cap() if you use boot_cpu_has() above.
> +return;
> +}
> +
> +socket = cpu_to_socket(cpu);
> +info = socket_info + socket;
> +if ( info->feat_mask )
> +return;
> +
> +INIT_LIST_HEAD(&info->feat_list);
> +spin_lock_init(&info->ref_lock);
> +
> +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 0, ®s);
> +if ( regs.b & PSR_RESOURCE_TYPE_L3 )
> +{
> +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 1, ®s);
> +
> +feat = feat_l3_cat;
> +/* psr_cpu_prepare will allocate it on subsequent CPU onlining. */
> +feat_l3_cat = NULL;
I don't think the comment is very useful: You've consumed the object,
so you simply should not leave a dangling pointer (or else you'd risk
multiple use).
> static void psr_cpu_init(void)
> {
> +if ( socket_info )
> +cpu_init_work();
> +
> psr_assoc_init();
> }
>
> static void psr_cpu_fini(unsigned int cpu)
> {
> +if ( socket_info )
> +cpu_fini_work(cpu);
> return;
> }
Is it really useful to use another layer of helper functions here?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 05/24] x86: refactor psr: implement Domain init/free and schedule flows.
>>> On 15.02.17 at 09:49, wrote:
> @@ -362,11 +370,33 @@ void psr_free_rmid(struct domain *d)
> d->arch.psr_rmid = 0;
> }
>
> +static inline unsigned int get_max_cos_max(const struct psr_socket_info
> *info)
While I see that the immediately following function (in context) is
inline too, please don't add such outside of headers unless the
function really wants to be inlined. Let the compiler chose what's
best in the common case. Since you also modify the following
function, dropping the inline there seems warranted too.
> @@ -408,14 +450,32 @@ int psr_set_l3_cbm(struct domain *d, unsigned int
> socket,
> return 0;
> }
>
> +/* Called with domain lock held, no extra lock needed for 'psr_cos_ids' */
> +static void psr_free_cos(struct domain *d)
> +{
> +if( !d->arch.psr_cos_ids )
> +return;
Pointless conditional.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 04/21] x86/xen: split off enlighten_pvh.c
On 02/03/17 18:53, Vitaly Kuznetsov wrote: > Create enlighten_pvh.c by splitting off PVH related code from enlighten.c, > put it under CONFIG_XEN_PVH. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 06/24] x86: refactor psr: implement get hw info flow.
>>> On 15.02.17 at 09:49, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -84,6 +84,7 @@ enum psr_feat_type {
> PSR_SOCKET_L3_CAT = 0,
> PSR_SOCKET_L3_CDP,
> PSR_SOCKET_L2_CAT,
> +PSR_SOCKET_UNKNOWN = 0x,
Any reason to use this value, instead of just the next sequential one?
> @@ -182,6 +186,24 @@ static void free_feature(struct psr_socket_info *info)
> }
> }
>
> +static enum psr_feat_type psr_cbm_type_to_feat_type(enum cbm_type type)
> +{
> +enum psr_feat_type feat_type;
> +
> +/* Judge if feature is enabled. */
> +switch ( type )
> +{
> +case PSR_CBM_TYPE_L3:
> +feat_type = PSR_SOCKET_L3_CAT;
> +break;
> +default:
> +feat_type = PSR_SOCKET_UNKNOWN;
> +break;
> +}
> +
> +return feat_type;
> +}
The comment ahead of the switch() doesn't seem to describe what's
being done - there certainly is no check here whether anything is
enabled or disabled.
> @@ -225,8 +247,22 @@ static unsigned int l3_cat_get_cos_max(const struct
> feat_node *feat)
> return feat->info.l3_cat_info.cos_max;
> }
>
> +static bool l3_cat_get_feat_info(const struct feat_node *feat,
> + uint32_t data[], unsigned int array_len)
> +{
> +if ( !data || 3 > array_len )
I think the 3 here was picked upon already: This check does not
guarantee there's no array overrun ...
> +return false;
> +
> +data[CBM_LEN] = feat->info.l3_cat_info.cbm_len;
> +data[COS_MAX] = feat->info.l3_cat_info.cos_max;
> +data[PSR_FLAG] = 0;
... anywhere here. For that you'd need a *_MAX- or *_NUM-type
constant (defined next to the array index constants).
> --- a/xen/arch/x86/sysctl.c
> +++ b/xen/arch/x86/sysctl.c
> @@ -176,15 +176,19 @@ long arch_do_sysctl(
> switch ( sysctl->u.psr_cat_op.cmd )
> {
> case XEN_SYSCTL_PSR_CAT_get_l3_info:
> -ret = psr_get_cat_l3_info(sysctl->u.psr_cat_op.target,
> -
> &sysctl->u.psr_cat_op.u.l3_info.cbm_len,
> -
> &sysctl->u.psr_cat_op.u.l3_info.cos_max,
> - &sysctl->u.psr_cat_op.u.l3_info.flags);
> +{
> +uint32_t data[3];
> +ret = psr_get_info(sysctl->u.psr_cat_op.target,
> + PSR_CBM_TYPE_L3, data, 3);
> +
> +sysctl->u.psr_cat_op.u.l3_info.cbm_len = data[CBM_LEN];
> +sysctl->u.psr_cat_op.u.l3_info.cos_max = data[COS_MAX];
> +sysctl->u.psr_cat_op.u.l3_info.flags = data[PSR_FLAG];
>
> if ( !ret && __copy_field_to_guest(u_sysctl, sysctl,
> u.psr_cat_op) )
> ret = -EFAULT;
> break;
> -
> +}
Please retain the blank line (after the } ).
> --- a/xen/include/asm-x86/psr.h
> +++ b/xen/include/asm-x86/psr.h
> @@ -19,19 +19,24 @@
> #include
>
> /* CAT cpuid level */
> -#define PSR_CPUID_LEVEL_CAT 0x10
> +#define PSR_CPUID_LEVEL_CAT0x10
>
> /* Resource Type Enumeration */
> -#define PSR_RESOURCE_TYPE_L30x2
> +#define PSR_RESOURCE_TYPE_L3 0x2
>
> /* L3 Monitoring Features */
> -#define PSR_CMT_L3_OCCUPANCY 0x1
> +#define PSR_CMT_L3_OCCUPANCY 0x1
>
> /* CDP Capability */
> -#define PSR_CAT_CDP_CAPABILITY (1u << 2)
> +#define PSR_CAT_CDP_CAPABILITY (1u << 2)
>
> /* L3 CDP Enable bit*/
> -#define PSR_L3_QOS_CDP_ENABLE_BIT 0x0
> +#define PSR_L3_QOS_CDP_ENABLE_BIT 0x0
Are all these adjustments really needed here?
> +/* Used by psr_get_info() */
> +#define CBM_LEN0
> +#define COS_MAX1
> +#define PSR_FLAG 2
Neither comment nor names are helpful to understand the purpose of
these constants. How about PSR_INFO_IDX_* or some such?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 05/21] x86/xen: split off enlighten_hvm.c
On 02/03/17 18:53, Vitaly Kuznetsov wrote: > Move PVHVM related code to enlighten_hvm.c. Three functions: > xen_cpuhp_setup(), xen_reboot(), xen_emergency_restart() are shared, drop > static qualifier from them. These functions will go to common code once > it is split from enlighten.c. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 06/21] x86/xen: split off enlighten_pv.c
On 02/03/17 18:53, Vitaly Kuznetsov wrote: > Basically, enlighten.c is renamed to enlighten_pv.c and some code moved > out to common enlighten.c. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 03/21] x86/xen: add CONFIG_XEN_PV to Kconfig
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> All code to supprot Xen PV will get under this new option. For the
s/supprot/support/
> beginning, check for it in the common code.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/kernel/cpu/hypervisor.c | 4 +++-
> arch/x86/kernel/process_64.c | 2 +-
> arch/x86/xen/Kconfig | 23 ++-
> 3 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/hypervisor.c
> b/arch/x86/kernel/cpu/hypervisor.c
> index a77f18d..ce6fcc3 100644
> --- a/arch/x86/kernel/cpu/hypervisor.c
> +++ b/arch/x86/kernel/cpu/hypervisor.c
> @@ -28,8 +28,10 @@
>
> static const __initconst struct hypervisor_x86 * const hypervisors[] =
> {
> -#ifdef CONFIG_XEN
> +#ifdef CONFIG_XEN_PV
> &x86_hyper_xen_pv,
> +#endif
> +#ifdef CONFIG_XEN_PVHVM
> &x86_hyper_xen_hvm,
> #endif
> &x86_hyper_vmware,
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index a61e141..5e8d129 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -438,7 +438,7 @@ __switch_to(struct task_struct *prev_p, struct
> task_struct *next_p)
>task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV))
> __switch_to_xtra(prev_p, next_p, tss);
>
> -#ifdef CONFIG_XEN
> +#ifdef CONFIG_XEN_PV
> /*
>* On Xen PV, IOPL bits in pt_regs->flags have no effect, and
>* current_pt_regs()->flags may not match the current task's
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 76b6dbd..c387560 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -6,7 +6,6 @@ config XEN
> bool "Xen guest support"
> depends on PARAVIRT
> select PARAVIRT_CLOCK
> - select XEN_HAVE_PVMMU
> select XEN_HAVE_VPMU
> depends on X86_64 || (X86_32 && X86_PAE)
> depends on X86_LOCAL_APIC && X86_TSC
> @@ -15,18 +14,32 @@ config XEN
> kernel to boot in a paravirtualized environment under the
> Xen hypervisor.
>
> +config XEN_PV
> + bool "Xen PV guest support"
> + default y
> + depends on XEN
select XEN_HAVE_PVMMU is missing ...
> + help
> + Support running as a Xen PV guest.
> +
> config XEN_DOM0
> - def_bool y
> - depends on XEN && PCI_XEN && SWIOTLB_XEN
> + bool "Xen PV Dom0 support"
> + default y
> + depends on XEN_PV && PCI_XEN && SWIOTLB_XEN
> depends on X86_IO_APIC && ACPI && PCI
> + select XEN_HAVE_PVMMU
... and can be dropped here
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup
>>> On 08.03.17 at 15:45, wrote: > I was looking at the backend code and see it is using DOMCTL command. I > guess it is considered that the console backend will be tied to a > specific Xen version. Am I correct? I don't think I'm qualified to talk about the console backend implementation (and possible quirks it has). Generally I'd expect backends not to use domctl-s, as that would tie them to the tool stack domain. > so maybe we can introduce new domctl command for handling vUART. This > would avoid us to commit on an ABI and allow us to extend it if > necessary in the future to support multiple UARTs. Well, without having the context of who it would be to use such a domctl (and for what purpose) I don#t think I can comment here. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 06/28] ARM: GICv3 ITS: introduce ITS command handling
On 07/03/17 18:08, Andre Przywara wrote:
Hi Julien,
Hi Andre,
On 06/02/17 19:16, Julien Grall wrote:
Hi Andre,
On 30/01/17 18:31, Andre Przywara wrote:
To be able to easily send commands to the ITS, create the respective
wrapper functions, which take care of the ring buffer.
The first two commands we implement provide methods to map a collection
to a redistributor (aka host core) and to flush the command queue (SYNC).
Start using these commands for mapping one collection to each host CPU.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3-its.c | 142
+-
xen/arch/arm/gic-v3-lpi.c | 20 ++
xen/arch/arm/gic-v3.c | 18 -
xen/include/asm-arm/gic_v3_defs.h | 2 +
xen/include/asm-arm/gic_v3_its.h | 36 ++
5 files changed, 215 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index ad7cd2a..6578e8a 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,6 +30,98 @@
#define ITS_CMD_QUEUE_SZSZ_64K
+#define BUFPTR_MASK GENMASK(19, 5)
+static int its_send_command(struct host_its *hw_its, const void
*its_cmd)
+{
+uint64_t readp, writep;
+
+spin_lock(&hw_its->cmd_lock);
Do you never expect a command to be sent in an interrupt path? I could
see at least one, we may decide to throttle the number of LPIs received
by a guest so this would involve disabling the interrupt.
I take it you are asking for spin_lock_irq[save]()?
Yes.
I don't think queuing ITS commands in interrupt context is a good idea,
especially since I just introduced a grace period to wait for a draining
command queue.
I am happy to revisit this when needed.
As mentioned on the previous mail, we might need to send a command
whilst in the interrupt context if we need to disable an interrupt that
fire too often.
I would be fine to have an ASSERT(!in_irq()) and a comment explaining
why for the time being.
+
+readp = readq_relaxed(hw_its->its_base + GITS_CREADR) & BUFPTR_MASK;
+writep = readq_relaxed(hw_its->its_base + GITS_CWRITER) &
BUFPTR_MASK;
+
+if ( ((writep + ITS_CMD_SIZE) % ITS_CMD_QUEUE_SZ) == readp )
+{
I look at all the series applied and there is no error message at all
when the queue is full. This will make difficult to see what's going on.
Furthermore, this limit could be easily reached. Furthermore, this could
happen easily if you decide to map a device with thousands of
interrupts. For instance the function gicv3_map_its_map_host_events will
issue 2 commands per event (MAPTI and INV).
So how do you plan to address this?
So I changed this now to wait for 1 ms (or whatever value you prefer) in
hope the command queue drains. In the end the ITS is hardware, so
processing commands it's the only thing it does and I don't expect it to
be seriously stalled, usually. So waiting a tiny bit to cover this odd
case of command queue contention seems useful to me, especially since we
only send commands from non-critical Dom0 code.
I don't have any idea of a good value. My worry with such value is you
are only hoping it will never happen. If you fail here, what will you
do? You will likely have to revert changes which mean more command and
then? If it fails once, why would it not fail again? You will end up in
a spiral loop.
Regarding the value, is it something we could confirm with the hardware
guys?
The command queue is now 1 MB in size, so we have 32,768 commands in
there. Should be enough for everybody ;-)
+spin_unlock(&hw_its->cmd_lock);
+return -EBUSY;
+}
+
+memcpy(hw_its->cmd_buf + writep, its_cmd, ITS_CMD_SIZE);
+if ( hw_its->flags & HOST_ITS_FLUSH_CMD_QUEUE )
+__flush_dcache_area(hw_its->cmd_buf + writep, ITS_CMD_SIZE);
Please use dcache_ helpers.
+else
+dsb(ishst);
+
+writep = (writep + ITS_CMD_SIZE) % ITS_CMD_QUEUE_SZ;
+writeq_relaxed(writep & BUFPTR_MASK, hw_its->its_base +
GITS_CWRITER);
+
+spin_unlock(&hw_its->cmd_lock);
+
+return 0;
+}
+
+static uint64_t encode_rdbase(struct host_its *hw_its, int cpu,
uint64_t reg)
s/int cpu/unsigned int cpu/
So it's easy to do so, but why is that actually?
Because a CPU and a vCPU ID cannot be signed. So what's the point to
make them signed except saving 9 characters?
I see that both "processor" and "vcpu_id" are "int" in struct vcpu, so I
was using int as the type for CPUs here as well.
[...]
+{
+struct host_its *its;
+int ret;
+
+list_for_each_entry(its, &host_its_list, entry)
+{
+/*
+ * This function is called on CPU0 before any ITSes have been
+ * properly initialized. Skip the collection setup in this case,
+ * it will be done explicitly for CPU0 upon initializing the
ITS.
+ */
Looking at the code, I
Re: [Xen-devel] [PATCH v7 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.
On 3/8/2017 10:06 PM, Paul Durrant wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Yu
Zhang
Sent: 08 March 2017 13:32
To: xen-devel@lists.xen.org
Cc: zhiyuan...@intel.com
Subject: [Xen-devel] [PATCH v7 1/5] x86/ioreq server: Release the p2m lock
after mmio is handled.
Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
select the ioreq server. For example, operations on gfns with
p2m_ioreq_server type will be delivered to a corresponding ioreq
server, and this requires that the p2m type not be switched back
to p2m_ram_rw during the emulation process. To avoid this race
condition, we delay the release of p2m lock in
hvm_hap_nested_page_fault()
until mmio is handled.
Note: previously in hvm_hap_nested_page_fault(), put_gfn() was moved
before the handling of mmio, due to a deadlock risk between the p2m
lock and the event lock(in commit 77b8dfe). Later, a per-event channel
lock was introduced in commit de6acb7, to send events. So we do not
need to worry about the deadlock issue.
Signed-off-by: Yu Zhang
Reviewed-by: Jan Beulich
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Your cc-s seem to have been dropped by your mailer (or at least I can't see
them in the mail header). You may want to send these again so that relevant
folks actually get cc-ed.
Thanks for your remind. Let me try again. This is strange because I had
commented out supress-cc in my git config.
Please ignore this thread, and sorry for the inconvenience. :-)
Yu
Paul
---
xen/arch/x86/hvm/hvm.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ccfae4f..a9db7f7 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa,
unsigned long gla,
(npfec.write_access &&
(p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
{
-__put_gfn(p2m, gfn);
-if ( ap2m_active )
-__put_gfn(hostp2m, gfn);
-
rc = 0;
if ( unlikely(is_pvh_domain(currd)) )
-goto out;
+goto out_put_gfn;
if ( !handle_mmio_with_translation(gla, gpa >> PAGE_SHIFT, npfec) )
hvm_inject_hw_exception(TRAP_gp_fault, 0);
rc = 1;
-goto out;
+goto out_put_gfn;
}
/* Check if the page has been paged out */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 07/24] x86: refactor psr: implement get value flow.
>>> On 15.02.17 at 09:49, wrote:
> @@ -260,9 +263,22 @@ static bool l3_cat_get_feat_info(const struct feat_node
> *feat,
> return true;
> }
>
> +static bool l3_cat_get_val(const struct feat_node *feat, unsigned int cos,
> + enum cbm_type type, uint64_t *val)
> +{
> +if ( cos > feat->info.l3_cat_info.cos_max )
> +/* Use default value. */
> +cos = 0;
> +
> +*val = feat->cos_reg_val[cos];
> +
> +return true;
This one never failing I wonder whether the same will apply to the
later ones. If so, there's little point in returning a boolean here, but
instead you could return the value instead of using indirection.
> static void __init parse_psr_bool(char *s, char *value, char *feature,
> @@ -482,12 +498,14 @@ static struct psr_socket_info *get_socket_info(unsigned
> int socket)
> return socket_info + socket;
> }
>
> -int psr_get_info(unsigned int socket, enum cbm_type type,
> - uint32_t data[], unsigned int array_len)
> +static int psr_get(unsigned int socket, enum cbm_type type,
The immediately preceding patch introduced thus function, and
now you're changing its name. Please give it the intended final
name right away.
> + uint32_t data[], unsigned int array_len,
> + struct domain *d, uint64_t *val)
const struct domain *, but I'm not even sure that's an appropriate
parameter here:
> @@ -498,6 +516,15 @@ int psr_get_info(unsigned int socket, enum cbm_type type,
> if ( feat->feature != feat_type )
> continue;
>
> +if ( d )
> +{
> +cos = d->arch.psr_cos_ids[socket];
You could equally well pass a more constrained pointer, like
psr_cos_ids[] on its own. But of course much depends on whether
you'll need d for other things in this function in later patches.
> +if ( feat->ops.get_val(feat, cos, type, val) )
> +return 0;
> +else
> +break;
> +}
> +
> if ( feat->ops.get_feat_info(feat, data, array_len) )
> return 0;
> else
Looking at the context here - is it really a good idea to overload the
function in this way, rather than creating a second one? Your
only complicating the live of the callers, as can be seen e.g. ...
> @@ -507,10 +534,16 @@ int psr_get_info(unsigned int socket, enum cbm_type
> type,
> return -ENOENT;
> }
>
> -int psr_get_l3_cbm(struct domain *d, unsigned int socket,
> - uint64_t *cbm, enum cbm_type type)
> +int psr_get_info(unsigned int socket, enum cbm_type type,
> + uint32_t data[], unsigned int array_len)
> +{
> +return psr_get(socket, type, data, array_len, NULL, NULL);
... here and ...
> +}
> +
> +int psr_get_val(struct domain *d, unsigned int socket,
> +uint64_t *val, enum cbm_type type)
> {
> -return 0;
> +return psr_get(socket, type, NULL, 0, d, val);
> }
... here (it is a bad sign that both pass NULL on either side).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 106543: tolerable FAIL - PUSHED
flight 106543 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/106543/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 106510 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 106510 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 106510 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass build-arm64-xsm 5 xen-buildfail never pass build-arm64 5 xen-buildfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass build-arm64-pvops 5 kernel-build fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass version targeted for testing: libvirt 9d60ea31dd1233756128768cf77b21b7c647d85d baseline version: libvirt 3898526931334e88ea8101dd3afa9fb90be9dc48 Last test of basis 106510 2017-03-07 04:20:11 Z1 days Testing same since 106543 2017-03-08 04:20:51 Z0 days1 attempts People who touched revisions under test: Cole Robinson John Ferlan Nitesh Konkar Nitesh Konkar Pavel Hrdina Peter Krempa jobs: build-amd64-xsm pass build-arm64-xsm fail build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 fail build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopsfail build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config 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/
[Xen-devel] [PATCH] x86/emul: Poision the stubs with debug traps
...rather than leaving fragments of old instructions in place. This reduces
the chances of something going further-wrong (as the debug trap will be cause
and terminate the guest) in a cascade-failure where we end up executing the
instruction fragments.
Before:
(XEN) d2v0 exception 6 (ec=) in emulation stub (line 6239)
(XEN) d2v0 stub: c4 e1 44 77 c3 80 d0 82 ff ff ff d1 90 ec 90
After:
(XEN) d3v0 exception 6 (ec=) in emulation stub (line 6239)
(XEN) d3v0 stub: c4 e1 44 77 c3 cc cc cc cc cc cc cc cc cc cc
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
Semi-RFC: I really don't like (ab)use of memset, but can't think of a cleaner
way of doing this.
---
xen/arch/x86/x86_emulate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/x86_emulate.c b/xen/arch/x86/x86_emulate.c
index 51df340..cc334ca 100644
--- a/xen/arch/x86/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate.c
@@ -30,8 +30,8 @@
BUILD_BUG_ON(STUB_BUF_SIZE / 2 < MAX_INST_LEN + 1); \
ASSERT(!(stb).ptr); \
(stb).addr = this_cpu(stubs.addr) + STUB_BUF_SIZE / 2; \
-((stb).ptr = map_domain_page(_mfn(this_cpu(stubs.mfn + \
-((stb).addr & ~PAGE_MASK); \
+memset(((stb).ptr = map_domain_page(_mfn(this_cpu(stubs.mfn + \
+ ((stb).addr & ~PAGE_MASK), 0xcc, STUB_BUF_SIZE / 2);\
})
#define put_stub(stb) ({ \
if ( (stb).ptr ) \
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 0/5] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.
XenGT leverages ioreq server to track and forward the accesses to GPU I/O resources, e.g. the PPGTT(per-process graphic translation tables). Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges to be emulated. To select an ioreq server, the rangeset is searched to see if the I/O range is recorded. However, number of ram pages to be tracked may exceed the upper limit of rangeset. Previously, one solution was proposed to refactor the rangeset, and extend its upper limit. However, after 12 rounds discussion, we have decided to drop this approach due to security concerns. Now this new patch series introduces a new mem type, HVMMEM_ioreq_server, and added hvm operations to let one ioreq server to claim its ownership of ram pages with this type. Accesses to a page of this type will be handled by the specified ioreq server directly. Yu Zhang (5): x86/ioreq server: Release the p2m lock after mmio is handled. x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server. x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server pages. ix86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries. x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps. xen/arch/x86/hvm/dm.c| 79 +++-- xen/arch/x86/hvm/emulate.c | 99 ++- xen/arch/x86/hvm/hvm.c | 8 +-- xen/arch/x86/hvm/ioreq.c | 46 +++ xen/arch/x86/mm/hap/hap.c| 9 +++ xen/arch/x86/mm/hap/nested_hap.c | 2 +- xen/arch/x86/mm/p2m-ept.c| 16 - xen/arch/x86/mm/p2m-pt.c | 33 --- xen/arch/x86/mm/p2m.c| 123 +++ xen/arch/x86/mm/shadow/multi.c | 3 +- xen/include/asm-x86/hvm/ioreq.h | 2 + xen/include/asm-x86/p2m.h| 40 +++-- xen/include/public/hvm/dm_op.h | 29 - xen/include/public/hvm/hvm_op.h | 8 ++- 14 files changed, 463 insertions(+), 34 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 2/5] x86/ioreq server: Add DMOP to map guest ram with p2m_ioreq_server to an ioreq server.
A new DMOP - XEN_DMOP_map_mem_type_to_ioreq_server, is added to let one ioreq server claim/disclaim its responsibility for the handling of guest pages with p2m type p2m_ioreq_server. Users of this DMOP can specify which kind of operation is supposed to be emulated in a parameter named flags. Currently, this DMOP only support the emulation of write operations. And it can be further extended to support the emulation of read ones if an ioreq server has such requirement in the future. For now, we only support one ioreq server for this p2m type, so once an ioreq server has claimed its ownership, subsequent calls of the XEN_DMOP_map_mem_type_to_ioreq_server will fail. Users can also disclaim the ownership of guest ram pages with p2m_ioreq_server, by triggering this new DMOP, with ioreq server id set to the current owner's and flags parameter set to 0. Note both XEN_DMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server are only supported for HVMs with HAP enabled. Also note that only after one ioreq server claims its ownership of p2m_ioreq_server, will the p2m type change to p2m_ioreq_server be allowed. Signed-off-by: Paul Durrant Signed-off-by: Yu Zhang Acked-by: Tim Deegan --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Paul Durrant Cc: George Dunlap Cc: Jun Nakajima Cc: Kevin Tian Cc: Tim Deegan changes in v7: - Use new ioreq server interface - XEN_DMOP_map_mem_type_to_ioreq_server. - According to comments from George: removed domain_pause/unpause() in hvm_map_mem_type_to_ioreq_server(), because it's too expensive, and we can avoid the: a> deadlock between p2m lock and ioreq server lock by using these locks in the same order - solved in patch 4; b> for race condition between vm exit and ioreq server unbinding, we can just retry this instruction. - According to comments from Jan and George: continue to clarify logic in hvmemul_do_io(). - According to comments from Jan: clarify comment in p2m_set_ioreq_server(). changes in v6: - Clarify logic in hvmemul_do_io(). - Use recursive lock for ioreq server lock. - Remove debug print when mapping ioreq server. - Clarify code in ept_p2m_type_to_flags() for consistency. - Remove definition of P2M_IOREQ_HANDLE_WRITE_ACCESS. - Add comments for HVMMEM_ioreq_server to note only changes to/from HVMMEM_ram_rw are permitted. - Add domain_pause/unpause() in hvm_map_mem_type_to_ioreq_server() to avoid the race condition when a vm exit happens on a write- protected page, just to find the ioreq server has been unmapped already. - Introduce a seperate patch to delay the release of p2m lock to avoid the race condition. - Introduce a seperate patch to handle the read-modify-write operations on a write protected page. changes in v5: - Simplify logic in hvmemul_do_io(). - Use natual width types instead of fixed width types when possible. - Do not grant executable permission for p2m_ioreq_server entries. - Clarify comments and commit message. - Introduce a seperate patch to recalculate the p2m types after the ioreq server unmaps the p2m_ioreq_server. changes in v4: - According to Paul's advice, add comments around the definition of HVMMEM_iore_server in hvm_op.h. - According to Wei Liu's comments, change the format of the commit message. changes in v3: - Only support write emulation in this patch; - Remove the code to handle race condition in hvmemul_do_io(), - No need to reset the p2m type after an ioreq server has disclaimed its ownership of p2m_ioreq_server; - Only allow p2m type change to p2m_ioreq_server after an ioreq server has claimed its ownership of p2m_ioreq_server; - Only allow p2m type change to p2m_ioreq_server from pages with type p2m_ram_rw, and vice versa; - HVMOP_map_mem_type_to_ioreq_server interface change - use uint16, instead of enum to specify the memory type; - Function prototype change to p2m_get_ioreq_server(); - Coding style changes; - Commit message changes; - Add Tim's Acked-by. changes in v2: - Only support HAP enabled HVMs; - Replace p2m_mem_type_changed() with p2m_change_entry_type_global() to reset the p2m type, when an ioreq server tries to claim/disclaim its ownership of p2m_ioreq_server; - Comments changes. --- xen/arch/x86/hvm/dm.c| 40 -- xen/arch/x86/hvm/emulate.c | 64 -- xen/arch/x86/hvm/ioreq.c | 38 + xen/arch/x86/mm/hap/nested_hap.c | 2 +- xen/arch/x86/mm/p2m-ept.c| 8 - xen/arch/x86/mm/p2m-pt.c | 20 +++ xen/arch/x86/mm/p2m.c| 74 xen/arch/x86/mm/shadow/multi.c | 3 +- xen/include/asm-x86/hvm/ioreq.h | 2 ++ xen/include/asm-x86/p2m.h| 26 -- xen/include/public/hvm/dm_op.h | 26 ++ xen/include/public/hvm/hvm_op.h | 8 - 12 files changed, 292 ins
[Xen-devel] [PATCH v7 3/5] x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server pages.
In ept_handle_violation(), write violations are also treated as
read violations. And when a VM is accessing a write-protected
address with read-modify-write instructions, the read emulation
process is triggered first.
For p2m_ioreq_server pages, current ioreq server only forwards
the write operations to the device model. Therefore when such page
is being accessed by a read-modify-write instruction, the read
operations should be emulated here in hypervisor. This patch provides
such a handler to copy the data to the buffer.
Note: MMIOs with p2m_mmio_dm type do not need such special treatment
because both reads and writes will go to the device mode.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
changes in v2:
- According to comments from Jan: rename mem_ops to ioreq_server_ops.
- According to comments from Jan: use hvm_copy_from_guest_phys() in
ioreq_server_read(), instead of do it by myself.
---
xen/arch/x86/hvm/emulate.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index fb56f7b..9744dcb 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -94,6 +94,26 @@ static const struct hvm_io_handler null_handler = {
.ops = &null_ops
};
+static int ioreq_server_read(const struct hvm_io_handler *io_handler,
+uint64_t addr,
+uint32_t size,
+uint64_t *data)
+{
+if ( hvm_copy_from_guest_phys(data, addr, size) != HVMCOPY_okay )
+return X86EMUL_UNHANDLEABLE;
+
+return X86EMUL_OKAY;
+}
+
+static const struct hvm_io_ops ioreq_server_ops = {
+.read = ioreq_server_read,
+.write = null_write
+};
+
+static const struct hvm_io_handler ioreq_server_handler = {
+.ops = &ioreq_server_ops
+};
+
static int hvmemul_do_io(
bool_t is_mmio, paddr_t addr, unsigned long *reps, unsigned int size,
uint8_t dir, bool_t df, bool_t data_is_addr, uintptr_t data)
@@ -197,6 +217,10 @@ static int hvmemul_do_io(
* - If the IOREQ_MEM_ACCESS_WRITE flag is not set, treat it
* like a normal PIO or MMIO that doesn't have an ioreq
* server (i.e., by ignoring it).
+ *
+ * - If the accesss is a read, this could be part of a
+ * read-modify-write instruction, emulate the read so that we
+ * have it.
*/
struct hvm_ioreq_server *s = NULL;
p2m_type_t p2mt = p2m_invalid;
@@ -226,6 +250,17 @@ static int hvmemul_do_io(
}
/*
+ * This is part of a read-modify-write instruction.
+ * Emulate the read part so we have the value cached.
+ */
+if ( dir == IOREQ_READ )
+{
+rc = hvm_process_io_intercept(&ioreq_server_handler, &p);
+vio->io_req.state = STATE_IOREQ_NONE;
+break;
+}
+
+/*
* If the IOREQ_MEM_ACCESS_WRITE flag is not set,
* we should set s to NULL, and just ignore such
* access.
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 4/5] ix86/ioreq server: Asynchronously reset outstanding p2m_ioreq_server entries.
After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
asynchronously with the current p2m_change_entry_type_global()
interface.
This patch also disallows live migration, when there's still any
outstanding p2m_ioreq_server entry left. The core reason is our
current implementation of p2m_change_entry_type_global() can not
tell the state of p2m_ioreq_server entries(can not decide if an
entry is to be emulated or to be resynced).
Signed-off-by: Yu Zhang
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jun Nakajima
Cc: Kevin Tian
changes in v3:
- Move the synchronously resetting logic into patch 5.
- According to comments from Jan: introduce p2m_check_changeable()
to clarify the p2m type change code.
- According to comments from George: use locks in the same order
to avoid deadlock, call p2m_change_entry_type_global() after unmap
of the ioreq server is finished.
changes in v2:
- Move the calculation of ioreq server page entry_cout into
p2m_change_type_one() so that we do not need a seperate lock.
Note: entry_count is also calculated in resolve_misconfig()/
do_recalc(), fortunately callers of both routines have p2m
lock protected already.
- Simplify logic in hvmop_set_mem_type().
- Introduce routine p2m_finish_type_change() to walk the p2m
table and do the p2m reset.
---
xen/arch/x86/hvm/ioreq.c | 8
xen/arch/x86/mm/hap/hap.c | 9 +
xen/arch/x86/mm/p2m-ept.c | 8 +++-
xen/arch/x86/mm/p2m-pt.c | 13 +++--
xen/arch/x86/mm/p2m.c | 20
xen/include/asm-x86/p2m.h | 9 -
6 files changed, 63 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index fcb9f38..c129eb4 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -949,6 +949,14 @@ int hvm_map_mem_type_to_ioreq_server(struct domain *d,
ioservid_t id,
spin_unlock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
+if ( rc == 0 && flags == 0 )
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+if ( read_atomic(&p2m->ioreq.entry_count) )
+p2m_change_entry_type_global(d, p2m_ioreq_server, p2m_ram_rw);
+}
+
return rc;
}
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index a57b385..f27a56f 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -187,6 +187,15 @@ out:
*/
static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+/*
+* Refuse to turn on global log-dirty mode if
+* there's outstanding p2m_ioreq_server pages.
+*/
+if ( log_global && read_atomic(&p2m->ioreq.entry_count) )
+return -EBUSY;
+
/* turn on PG_log_dirty bit in paging mode */
paging_lock(d);
d->arch.paging.mode |= PG_log_dirty;
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index cc1eb21..1df3d09 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -544,6 +544,12 @@ static int resolve_misconfig(struct p2m_domain *p2m,
unsigned long gfn)
e.ipat = ipat;
if ( e.recalc && p2m_is_changeable(e.sa_p2mt) )
{
+ if ( e.sa_p2mt == p2m_ioreq_server )
+ {
+ p2m->ioreq.entry_count--;
+ ASSERT(p2m->ioreq.entry_count >= 0);
+ }
+
e.sa_p2mt = p2m_is_logdirty_range(p2m, gfn + i, gfn +
i)
? p2m_ram_logdirty : p2m_ram_rw;
ept_p2m_type_to_flags(p2m, &e, e.sa_p2mt, e.access);
@@ -965,7 +971,7 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
if ( is_epte_valid(ept_entry) )
{
if ( (recalc || ept_entry->recalc) &&
- p2m_is_changeable(ept_entry->sa_p2mt) )
+ p2m_check_changeable(ept_entry->sa_p2mt) )
*t = p2m_is_logdirty_range(p2m, gfn, gfn) ? p2m_ram_logdirty
: p2m_ram_rw;
else
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 97dc25d..d9a7b76 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -437,11 +437,13 @@ static int do_recalc(struct p2m_domain *p2m, unsigned
long gfn)
needs_recalc(l1, *pent) )
{
l1_pgentry_t e = *pent;
+p2m_type_t p2mt_old;
if ( !valid_recalc(l1, e) )
P2M_DEBUG("bogus recalc leaf at d%d:%lx:%u\n",
p2m->domain->domain_id, gfn, level);
-if ( p2m_is_changeable(p2m_flags_to_type(l1e_get_flags(e))) )
+p2mt_old = p2m_flags_to_type(l1e_get_flags(e));
+if ( p2m_is_changeable(p2mt_old) )
{
unsigned long mask = ~
[Xen-devel] [PATCH v7 5/5] x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.
After an ioreq server has unmapped, the remaining p2m_ioreq_server
entries need to be reset back to p2m_ram_rw. This patch does this
synchronously by iterating the p2m table.
The synchronous resetting is necessary because we need to guarantee
the p2m table is clean before another ioreq server is mapped. And
since the sweeping of p2m table could be time consuming, it is done
with hypercall continuation.
Signed-off-by: Yu Zhang
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
changes in v1:
- This patch is splitted from patch 4 of last version.
- According to comments from Jan: update the gfn_start for
when use hypercall continuation to reset the p2m type.
- According to comments from Jan: use min() to compare gfn_end
and max mapped pfn in p2m_finish_type_change()
---
xen/arch/x86/hvm/dm.c | 43 +-
xen/arch/x86/mm/p2m.c | 29
xen/include/asm-x86/p2m.h | 5 +
xen/include/public/hvm/dm_op.h | 3 +--
4 files changed, 73 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index f97478b..a92d5d7 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -288,6 +288,7 @@ static int inject_event(struct domain *d,
return 0;
}
+#define DMOP_op_mask 0xff
static int dm_op(domid_t domid,
unsigned int nr_bufs,
xen_dm_op_buf_t bufs[])
@@ -315,10 +316,8 @@ static int dm_op(domid_t domid,
}
rc = -EINVAL;
-if ( op.pad )
-goto out;
-switch ( op.op )
+switch ( op.op & DMOP_op_mask )
{
case XEN_DMOP_create_ioreq_server:
{
@@ -387,6 +386,10 @@ static int dm_op(domid_t domid,
{
const struct xen_dm_op_map_mem_type_to_ioreq_server *data =
&op.u.map_mem_type_to_ioreq_server;
+unsigned long gfn_start = op.op & ~DMOP_op_mask;
+unsigned long gfn_end;
+
+const_op = false;
rc = -EINVAL;
if ( data->pad )
@@ -396,8 +399,38 @@ static int dm_op(domid_t domid,
if ( !hap_enabled(d) )
break;
-rc = hvm_map_mem_type_to_ioreq_server(d, data->id,
- data->type, data->flags);
+if ( gfn_start == 0 )
+rc = hvm_map_mem_type_to_ioreq_server(d, data->id,
+ data->type, data->flags);
+/*
+ * Iterate p2m table when an ioreq server unmaps from p2m_ioreq_server,
+ * and reset the remaining p2m_ioreq_server entries back to p2m_ram_rw.
+ */
+if ( (gfn_start > 0) || (data->flags == 0 && rc == 0) )
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+while ( read_atomic(&p2m->ioreq.entry_count) &&
+gfn_start <= p2m->max_mapped_pfn )
+{
+gfn_end = gfn_start + DMOP_op_mask;
+
+p2m_finish_type_change(d, gfn_start, gfn_end,
+ p2m_ioreq_server, p2m_ram_rw);
+
+gfn_start = gfn_end + 1;
+
+/* Check for continuation if it's not the last iteration. */
+if ( gfn_start <= p2m->max_mapped_pfn &&
+ hypercall_preempt_check() )
+{
+rc = -ERESTART;
+op.op |= gfn_start;
+break;
+}
+}
+}
+
break;
}
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 94d7141..9a81f00 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1038,6 +1038,35 @@ void p2m_change_type_range(struct domain *d,
p2m_unlock(p2m);
}
+/* Synchronously modify the p2m type of a range of gfns from ot to nt. */
+void p2m_finish_type_change(struct domain *d,
+unsigned long start, unsigned long end,
+p2m_type_t ot, p2m_type_t nt)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+p2m_type_t t;
+unsigned long gfn = start;
+
+ASSERT(start <= end);
+ASSERT(ot != nt);
+ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
+
+p2m_lock(p2m);
+
+end = min(end, p2m->max_mapped_pfn);
+while ( gfn <= end )
+{
+get_gfn_query_unlocked(d, gfn, &t);
+
+if ( t == ot )
+p2m_change_type_one(d, gfn, t, nt);
+
+gfn++;
+}
+
+p2m_unlock(p2m);
+}
+
/*
* Returns:
*0 for success
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index 395f125..3eadd89 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -611,6 +611,11 @@ void p2m_change_type_range(struct domain *d,
int p2m_change_type_one(struct domain *d, unsigned long gfn,
p2m_type_t ot, p2m_type_t nt);
+/* Synchronously change types across a range of p2m entries (start ... end) */
[Xen-devel] [PATCH v7 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.
Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
select the ioreq server. For example, operations on gfns with
p2m_ioreq_server type will be delivered to a corresponding ioreq
server, and this requires that the p2m type not be switched back
to p2m_ram_rw during the emulation process. To avoid this race
condition, we delay the release of p2m lock in hvm_hap_nested_page_fault()
until mmio is handled.
Note: previously in hvm_hap_nested_page_fault(), put_gfn() was moved
before the handling of mmio, due to a deadlock risk between the p2m
lock and the event lock(in commit 77b8dfe). Later, a per-event channel
lock was introduced in commit de6acb7, to send events. So we do not
need to worry about the deadlock issue.
Signed-off-by: Yu Zhang
Reviewed-by: Jan Beulich
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/hvm.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ccfae4f..a9db7f7 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned
long gla,
(npfec.write_access &&
(p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
{
-__put_gfn(p2m, gfn);
-if ( ap2m_active )
-__put_gfn(hostp2m, gfn);
-
rc = 0;
if ( unlikely(is_pvh_domain(currd)) )
-goto out;
+goto out_put_gfn;
if ( !handle_mmio_with_translation(gla, gpa >> PAGE_SHIFT, npfec) )
hvm_inject_hw_exception(TRAP_gp_fault, 0);
rc = 1;
-goto out;
+goto out_put_gfn;
}
/* Check if the page has been paged out */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 106551: tolerable trouble: broken/fail/pass - PUSHED
flight 106551 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106551/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen-buildfail never pass
build-arm64-pvops 5 kernel-build fail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen f9adc1e66098e96861af49ca2d5a223ad654dec6
baseline version:
xen 4361e80d228655b100bae5d19b489b39d20aa68d
Last test of basis 106536 2017-03-07 20:01:30 Z0 days
Testing same since 106551 2017-03-08 14:17:10 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
jobs:
build-amd64 pass
build-arm64 fail
build-armhf pass
build-amd64-libvirt pass
build-arm64-pvopsfail
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm broken
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 :
+ branch=xen-unstable-smoke
+ revision=f9adc1e66098e96861af49ca2d5a223ad654dec6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
f9adc1e66098e96861af49ca2d5a223ad654dec6
+ branch=xen-unstable-smoke
+ revision=f9adc1e66098e96861af49ca2d5a223ad654dec6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' xf9adc1e66098e96861af49ca2d5a223ad654dec6 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org
[Xen-devel] MSR IA32_MISC_ENABLE missing on AMD (OVMF use it now)
Hi, Recently, OVMF start to read MSR 0x1a0, which cause a General Protection fault on AMD, but not in Intel. OMVF does not handle it and crash. OVMF use msr 0x1a0, which seems to be IA32_MISC_ENABLE, to find out if the XD attribute can be use on page tables. From a recent run (OVMF output): http://logs.test-lab.xenproject.org/osstest/logs/106538/test-amd64-amd64-xl-qemuu-ovmf-amd64/rimava0---var-log-xen-osstest-serial-debianhvm.guest.osstest.log This is where the read is made: https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuPageTable.c#L196 It was first introduced in this commit: "UefiCpuPkg/CpuDxe: Add memory attribute setting." https://github.com/tianocore/edk2/commit/22292ed344b8512c838bdd162533198b51a51c0c Is this a missing feature in Xen or a bug in OVMF? Regards, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 08/24] x86: refactor psr: set value: implement framework.
>>> On 15.02.17 at 09:49, wrote:
> As set value flow is the most complicated one in psr, it will be
> divided to some patches to make things clearer. This patch
> implements the set value framework to show a whole picture firstly.
>
> It also changes domctl interface to make it more general.
>
> To make the set value flow be general and can support multiple features
> at same time, it includes below steps:
> 1. Get COS ID of current domain using.
What is the "using" here supposed to mean?
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -546,18 +546,214 @@ int psr_get_val(struct domain *d, unsigned int socket,
> return psr_get(socket, type, NULL, 0, d, val);
> }
>
> -int psr_set_l3_cbm(struct domain *d, unsigned int socket,
> - uint64_t cbm, enum cbm_type type)
> +/* Set value functions */
> +static unsigned int get_cos_num(const struct psr_socket_info *info)
> {
> return 0;
> }
>
> +static int assemble_val_array(uint64_t *val,
> + uint32_t array_len,
> + const struct psr_socket_info *info,
> + unsigned int old_cos)
> +{
> +return -EINVAL;
> +}
> +
> +static int set_new_val_to_array(uint64_t *val,
insert_new_val() ? And when talking about arrays, as indicated
before, please use [] notation instead of pointers. This is
particularly relevant when the function name suggests that it
would be "val" which gets inserted, but aiui it is really ...
> +uint32_t array_len,
> +const struct psr_socket_info *info,
> +enum psr_feat_type feat_type,
> +enum cbm_type type,
> +uint64_t m)
... "m". Therefore please also consider better naming of parameters.
> +static int write_psr_msr(unsigned int socket, unsigned int cos,
> + const uint64_t *val)
> +{
> +return -ENOENT;
> +}
Is this function intended you write just one MSR, or potentially many?
In the latter case the name would perhaps better be "write_psr_msrs()".
> +int psr_set_val(struct domain *d, unsigned int socket,
> +uint64_t val, enum cbm_type type)
> +{
> +unsigned int old_cos;
> +int cos, ret;
> +unsigned int *ref;
> +uint64_t *val_array;
> +struct psr_socket_info *info = get_socket_info(socket);
> +uint32_t array_len;
> +enum psr_feat_type feat_type;
> +
> +if ( IS_ERR(info) )
> +return PTR_ERR(info);
> +
> +feat_type = psr_cbm_type_to_feat_type(type);
> +if ( !test_bit(feat_type, &info->feat_mask) )
> +return -ENOENT;
> +
> +/*
> + * Step 0:
> + * old_cos means the COS ID current domain is using. By default, it is 0.
> + *
> + * For every COS ID, there is a reference count to record how many
> domains
> + * are using the COS register corresponding to this COS ID.
> + * - If ref[old_cos] is 0, that means this COS is not used by any domain.
> + * - If ref[old_cos] is 1, that means this COS is only used by current
> + * domain.
> + * - If ref[old_cos] is more than 1, that mean multiple domains are using
> + * this COS.
> + */
> +old_cos = d->arch.psr_cos_ids[socket];
> +if ( old_cos > MAX_COS_REG_CNT )
> +return -EOVERFLOW;
Doesn't this need to be >= ? And isn't this happening an indication
of a bug, i.e. shouldn't there be an ASSERT_UNREACHABLE() ahead
of the return?
> +ref = info->cos_ref;
> +
> +/*
> + * Step 1:
> + * Assemle a value array to store all featues cos_reg_val[old_cos].
Assemble ... features ...
> + * And, set the input val into array according to the feature's
> + * position in array.
> + */
> +array_len = get_cos_num(info);
> +val_array = xzalloc_array(uint64_t, array_len);
> +if ( !val_array )
> +return -ENOMEM;
> +
> +if ( (ret = assemble_val_array(val_array, array_len, info, old_cos)) !=
> 0 )
> +{
> +xfree(val_array);
> +return ret;
> +}
> +
> +if ( (ret = set_new_val_to_array(val_array, array_len, info,
> + feat_type, type, val)) != 0 )
> +{
> +xfree(val_array);
> +return ret;
> +}
> +
> +/*
> + * Lock here to make sure the ref is not changed during find and
> + * write process.
> + */
> +spin_lock(&info->ref_lock);
Once again I don't think the comment is very useful - what you say
is the ordinary purpose of acquiring a lock.
> +/*
> + * Step 2:
> + * Try to find if there is already a COS ID on which all features' values
> + * are same as the array. Then, we can reuse this COS ID.
> + */
> +cos = find_cos(val_array, array_len, feat_type, info);
> +if ( cos >= 0 )
> +{
> +if ( cos == old_cos )
> +{
> +spin_unlock(&info->ref_lock);
> +xfree(val
Re: [Xen-devel] [PATCH 06/28] ARM: GICv3 ITS: introduce ITS command handling
Hi,
On 08/03/17 15:28, Julien Grall wrote:
>
>
> On 07/03/17 18:08, Andre Przywara wrote:
>> Hi Julien,
>
> Hi Andre,
>
>>
>> On 06/02/17 19:16, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 30/01/17 18:31, Andre Przywara wrote:
To be able to easily send commands to the ITS, create the respective
wrapper functions, which take care of the ring buffer.
The first two commands we implement provide methods to map a collection
to a redistributor (aka host core) and to flush the command queue
(SYNC).
Start using these commands for mapping one collection to each host CPU.
Signed-off-by: Andre Przywara
---
xen/arch/arm/gic-v3-its.c | 142
+-
xen/arch/arm/gic-v3-lpi.c | 20 ++
xen/arch/arm/gic-v3.c | 18 -
xen/include/asm-arm/gic_v3_defs.h | 2 +
xen/include/asm-arm/gic_v3_its.h | 36 ++
5 files changed, 215 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index ad7cd2a..6578e8a 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,6 +30,98 @@
#define ITS_CMD_QUEUE_SZSZ_64K
+#define BUFPTR_MASK GENMASK(19, 5)
+static int its_send_command(struct host_its *hw_its, const void
*its_cmd)
+{
+uint64_t readp, writep;
+
+spin_lock(&hw_its->cmd_lock);
>>>
>>> Do you never expect a command to be sent in an interrupt path? I could
>>> see at least one, we may decide to throttle the number of LPIs received
>>> by a guest so this would involve disabling the interrupt.
>>
>> I take it you are asking for spin_lock_irq[save]()?
>
> Yes.
>
>> I don't think queuing ITS commands in interrupt context is a good idea,
>> especially since I just introduced a grace period to wait for a draining
>> command queue.
>> I am happy to revisit this when needed.
>
> As mentioned on the previous mail, we might need to send a command
> whilst in the interrupt context if we need to disable an interrupt that
> fire too often.
>
> I would be fine to have an ASSERT(!in_irq()) and a comment explaining
> why for the time being.
Done.
>>
+
+readp = readq_relaxed(hw_its->its_base + GITS_CREADR) &
BUFPTR_MASK;
+writep = readq_relaxed(hw_its->its_base + GITS_CWRITER) &
BUFPTR_MASK;
+
+if ( ((writep + ITS_CMD_SIZE) % ITS_CMD_QUEUE_SZ) == readp )
+{
>>>
>>> I look at all the series applied and there is no error message at all
>>> when the queue is full. This will make difficult to see what's going on.
>>>
>>> Furthermore, this limit could be easily reached. Furthermore, this could
>>> happen easily if you decide to map a device with thousands of
>>> interrupts. For instance the function gicv3_map_its_map_host_events will
>>> issue 2 commands per event (MAPTI and INV).
>>>
>>> So how do you plan to address this?
>>
>> So I changed this now to wait for 1 ms (or whatever value you prefer) in
>> hope the command queue drains. In the end the ITS is hardware, so
>> processing commands it's the only thing it does and I don't expect it to
>> be seriously stalled, usually. So waiting a tiny bit to cover this odd
>> case of command queue contention seems useful to me, especially since we
>> only send commands from non-critical Dom0 code.
>
> I don't have any idea of a good value. My worry with such value is you
> are only hoping it will never happen. If you fail here, what will you
> do? You will likely have to revert changes which mean more command and
> then? If it fails once, why would it not fail again? You will end up in
> a spiral loop.
>
> Regarding the value, is it something we could confirm with the hardware
> guys?
Let's move this bikesh^Wfine-tuning to a later point in time ;-)
>> The command queue is now 1 MB in size, so we have 32,768 commands in
>> there. Should be enough for everybody ;-)
>>
+spin_unlock(&hw_its->cmd_lock);
+return -EBUSY;
+}
+
+memcpy(hw_its->cmd_buf + writep, its_cmd, ITS_CMD_SIZE);
+if ( hw_its->flags & HOST_ITS_FLUSH_CMD_QUEUE )
+__flush_dcache_area(hw_its->cmd_buf + writep, ITS_CMD_SIZE);
>>>
>>> Please use dcache_ helpers.
>>>
+else
+dsb(ishst);
+
+writep = (writep + ITS_CMD_SIZE) % ITS_CMD_QUEUE_SZ;
+writeq_relaxed(writep & BUFPTR_MASK, hw_its->its_base +
GITS_CWRITER);
+
+spin_unlock(&hw_its->cmd_lock);
+
+return 0;
+}
+
+static uint64_t encode_rdbase(struct host_its *hw_its, int cpu,
uint64_t reg)
>>>
>>> s/int cpu/unsigned int cpu/
>>
>> So it's easy to do so, but why is that actually?
>
> Because a
Re: [Xen-devel] MSR IA32_MISC_ENABLE missing on AMD (OVMF use it now)
On 03/08/2017 10:59 AM, Anthony PERARD wrote: > Hi, > > Recently, OVMF start to read MSR 0x1a0, which cause a General Protection > fault on AMD, but not in Intel. OMVF does not handle it and crash. I don't think this MSR exists on AMD processors so that would be OVMF bug. -boris > > OVMF use msr 0x1a0, which seems to be IA32_MISC_ENABLE, to find out if > the XD attribute can be use on page tables. > > From a recent run (OVMF output): > http://logs.test-lab.xenproject.org/osstest/logs/106538/test-amd64-amd64-xl-qemuu-ovmf-amd64/rimava0---var-log-xen-osstest-serial-debianhvm.guest.osstest.log > > This is where the read is made: > https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuPageTable.c#L196 > > It was first introduced in this commit: > "UefiCpuPkg/CpuDxe: Add memory attribute setting." > https://github.com/tianocore/edk2/commit/22292ed344b8512c838bdd162533198b51a51c0c > > Is this a missing feature in Xen or a bug in OVMF? > > Regards, > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/emul: Poision the stubs with debug traps
>>> On 08.03.17 at 16:39, wrote: > ...rather than leaving fragments of old instructions in place. This reduces > the chances of something going further-wrong (as the debug trap will be cause > and terminate the guest) in a cascade-failure where we end up executing the > instruction fragments. Where are you taking the "and terminate the guest" from? As far as I can see, do_int3() does nothing at all for an INT3 from hypervisor context (without CRASH_DEBUG), so we'd just take a row of INT3s until we hit the end of stub space (running either past the page boundary or into the next CPU's stub space, which is the syscall entry code). > Before: > (XEN) d2v0 exception 6 (ec=) in emulation stub (line 6239) > (XEN) d2v0 stub: c4 e1 44 77 c3 80 d0 82 ff ff ff d1 90 ec 90 Hmm, this is concerning: I don't think we have ways to generate 15-byte instructions into the stub, so where are all these non-zero bytes coming from? After all alloc_stub_page() pre-fills the page with all 0xCC. > After: > (XEN) d3v0 exception 6 (ec=) in emulation stub (line 6239) > (XEN) d3v0 stub: c4 e1 44 77 c3 cc cc cc cc cc cc cc cc cc cc > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > > Semi-RFC: I really don't like (ab)use of memset, but can't think of a cleaner > way of doing this. What abuse are you seeing here? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] MSR IA32_MISC_ENABLE missing on AMD (OVMF use it now)
>>> On 08.03.17 at 16:59, wrote: > Is this a missing feature in Xen or a bug in OVMF? The easiest way for you or them to find out is to try reading the MSR on bare hardware on an AMD system. But see also Boris' reply. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing test] 106542: regressions - trouble: broken/fail/pass
flight 106542 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/106542/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 3 host-install(3) broken REGR. vs. 105991 test-armhf-armhf-xl-vhd 6 xen-boot fail REGR. vs. 105991 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 105991 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start.2fail REGR. vs. 105991 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105991 test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105991 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105991 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105991 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105991 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105991 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 105991 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-1 63 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-2 63 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-5 63 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-3 63 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-xtf-amd64-amd64-4 63 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass version targeted for testing: xen b0577dd0c600241abcaddeb8d75abb0d956fdae3 baseline version: xen e9fbb8eb834b21a6f0ed18f41e35baa74ada3205 Last test of basis 105991 2017-02-22 17:09:42 Z 13 days Failing since106529 2017-03-07 16:41:56 Z0 days2 attempts Testing same since 106542 2017-03-08 02:00:50 Z0 days1 attempts People who touched revisions under test: Edgar E. Iglesias Jan Beulich Stefano Stabellini jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev
Re: [Xen-devel] [PATCH v16 4/9] x86: add multiboot2 protocol support for EFI platforms
..snip..
> > Now in the process I discovered that my patch for grub-mkconfig to
> > detect multiboot2 payloads and use those instead of multiboot never
> > made it upstream, so I had to modify my grub.cfg by hand (see below).
>
> It will be nice if you post it after GRUB2 2.02 release.
OK, I will wait (but attaching it here).
>From 89a85f31602f6d5f7355ffe6e246059e63cab973 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Wed, 8 Mar 2017 11:42:43 -0500
Subject: [PATCH] Use grub-file to figure out whether multiboot2 should be used
for Xen.gz
The multiboot2 is much more preferable than multiboot. Especially
if booting under EFI where multiboot does not have the functionality
to pass ImageHandler.
Signed-off-by: Konrad Rzeszutek Wilk
---
util/grub.d/20_linux_xen.in | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index c48af94..7aae59f 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -85,6 +85,10 @@ linux_entry ()
type="$4"
args="$5"
xen_args="$6"
+ ver=""
+ if $($grub_file --is-x86-multiboot2 ${xen_dirname}/${xen_basename}); then
+ ver="2"
+ fi
if [ -z "$boot_device_id" ]; then
boot_device_id="$(grub_get_device_id "${GRUB_DEVICE}")"
fi
@@ -122,16 +126,16 @@ linux_entry ()
else
xen_rm_opts="no-real-mode edd=off"
fi
- multiboot ${rel_xen_dirname}/${xen_basename} placeholder
${xen_args} \${xen_rm_opts}
+ multiboot${ver} ${rel_xen_dirname}/${xen_basename} placeholder
${xen_args} \${xen_rm_opts}
echo'$(echo "$lmessage" | grub_quote)'
- module ${rel_dirname}/${basename} placeholder
root=${linux_root_device_thisversion} ro ${args}
+ module${ver}${rel_dirname}/${basename} placeholder
root=${linux_root_device_thisversion} ro ${args}
EOF
if test -n "${initrd}" ; then
# TRANSLATORS: ramdisk isn't identifier. Should be translated.
message="$(gettext_printf "Loading initial ramdisk ...")"
sed "s/^/$submenu_indentation/" << EOF
echo'$(echo "$message" | grub_quote)'
- module --nounzip ${rel_dirname}/${initrd}
+ module${ver}--nounzip ${rel_dirname}/${initrd}
EOF
fi
sed "s/^/$submenu_indentation/" << EOF
--
2.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 09/24] x86: refactor psr: set value: assemble features value array.
>>> On 15.02.17 at 09:49, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -119,6 +119,32 @@ struct feat_ops {
> /* get_val is used to get feature COS register value. */
> bool (*get_val)(const struct feat_node *feat, unsigned int cos,
> enum cbm_type type, uint64_t *val);
> +/*
> + * get_cos_num is used to get the COS registers amount used by the
> + * feature for one setting, e.g. CDP uses 2 COSs but CAT uses 1.
> + */
> +unsigned int (*get_cos_num)(const struct feat_node *feat);
Please have blank lines ahead of every separating comment. (Of
course this then may need to start already in earlier patches.)
> +/*
> + * get_old_val and set_new_val are a pair of functions called in order.
> + * The caller will traverse all features in the list and call both
> + * functions for every feature to do below two things:
> + * 1. get old_cos register value of all supported features and
> + * 2. set the new value for the feature.
This is misleading, I think: I don't think a new value is being set for
every feature. This should be worded less ambiguously.
> @@ -207,6 +233,29 @@ static enum psr_feat_type psr_cbm_type_to_feat_type(enum
> cbm_type type)
> return feat_type;
> }
>
> +static bool psr_check_cbm(unsigned int cbm_len, uint64_t cbm)
> +{
> +unsigned int first_bit, zero_bit;
> +
> +/* Set bits should only in the range of [0, cbm_len). */
> +if ( cbm & (~0ull << cbm_len) )
This will not do what you intend for cbm_len == 64.
> +static int l3_cat_get_old_val(uint64_t val[],
> + const struct feat_node *feat,
> + unsigned int old_cos)
> +{
> +if ( old_cos > feat->info.l3_cat_info.cos_max )
Afaics this condition is the only L3 CAT specific thing in this function.
Should more of it be moved into common code? Same below for
set_new_val.
> -static int assemble_val_array(uint64_t *val,
> +static int combine_val_array(uint64_t *val,
Same comment as earlier on - please decide for a final name right
when introducing a function. In fact I'd prefer it to remain
"assemble".
> {
> -return -EINVAL;
> +const struct feat_node *feat;
> +int ret;
> +uint64_t *val_tmp = val;
I don't really see the need for this helper variable. Simply ...
> +if ( !val )
> +return -EINVAL;
> +
> +/* Get all features current values according to old_cos. */
> +list_for_each_entry(feat, &info->feat_list, list)
> +{
> +/* value getting order is same as feature list */
> +ret = feat->ops.get_old_val(val_tmp, feat, old_cos);
> +if ( ret )
> +return ret;
> +
> +val_tmp += feat->ops.get_cos_num(feat);
... use val here, after checking the return value against
array_len, and the also subtract from array_len. (I am averse
to _tmp suffixes, I'm sorry.)
Btw - for any of the later features, does their get_cos_num() ever
return other than a constant value? If not, there's no point in making
this a function call - you could simply have a numeric member in the
structure.
> @@ -567,7 +678,37 @@ static int set_new_val_to_array(uint64_t *val,
> enum cbm_type type,
> uint64_t m)
> {
> -return -EINVAL;
> +const struct feat_node *feat;
> +int ret;
> +uint64_t *val_tmp = val;
> +
> +/* Set new value into array according to feature's position in array. */
> +list_for_each_entry(feat, &info->feat_list, list)
> +{
> +if ( feat->feature != feat_type )
> +{
> +val_tmp += feat->ops.get_cos_num(feat);
> +if ( val_tmp - val > array_len)
> +return -ENOSPC;
> +
> +continue;
> +}
> +
> +/*
> + * Value setting position is same as feature list.
> + * Different features may have different setting behaviors, e.g. CDP
> + * has two values (DATA/CODE) which need us to save input value to
> + * different position in the array according to type, so we have to
> + * maintain a callback function.
> + */
> +ret = feat->ops.set_new_val(val_tmp, feat, type, m);
> +if ( ret )
> +return ret;
> +else
Pointless "else" again. I think I'll try to avoid pointing this out, should
more of these appear - please simply go through yourself any remove
any such uses.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 10/24] x86: refactor psr: set value: implement cos finding flow.
>>> On 15.02.17 at 09:49, wrote:
> Continue with patch:
???
> 'x86: refactor psr: set value: assemble features value array'
Or did you perhaps mean "continue from"?
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -145,6 +145,19 @@ struct feat_ops {
> const struct feat_node *feat,
> enum cbm_type type,
> uint64_t m);
> +/*
> + * compare_val is used in set value process to compare if the
> + * input value array can match all the features' COS registers values
> + * according to input cos id.
> + *
> + * The return value is the amount of entries to skip in the value array
> + * or error.
> + * 1 - one entry in value array.
> + * 2 - two entries in value array, e.g. CDP uses two entries.
Isn't this get_cos_num()'s result again? Or, looking at the function
below, is the comment simply stale?
> @@ -356,6 +369,34 @@ static int l3_cat_set_new_val(uint64_t val[],
> return 0;
> }
>
> +static int l3_cat_compare_val(const uint64_t val[],
> + const struct feat_node *feat,
> + unsigned int cos, bool *found)
> +{
> +uint64_t l3_def_cbm;
> +
> +l3_def_cbm = (1ull << feat->info.l3_cat_info.cbm_len) - 1;
Please only calculate the value on the path you need it. Also this
will again degenerate of cbm_len == 64.
> +/*
> + * Different features' cos_max are different. If cos id of the feature
> + * being set exceeds other feature's cos_max, the val of other feature
> + * must be default value. HW supports such case.
> + */
> +if ( cos > feat->info.l3_cat_info.cos_max )
> +{
> +if ( val[0] != l3_def_cbm )
> +{
> +*found = false;
> +return -ENOENT;
What is the difference between this "not found" and ...
> +}
> +*found = true;
> +}
> +else
> +*found = (val[0] == feat->cos_reg_val[cos]);
> +
> +return 0;
... the possible one here? I.e. why once -ENOENT and once 0 as
return value?
> @@ -715,6 +757,57 @@ static int find_cos(const uint64_t *val, uint32_t
> array_len,
> enum psr_feat_type feat_type,
> const struct psr_socket_info *info)
> {
> +unsigned int cos;
> +const unsigned int *ref = info->cos_ref;
> +const struct feat_node *feat;
> +const uint64_t *val_tmp = val;
> +int ret;
> +bool found = false;
> +unsigned int cos_max = 0;
> +
> +/* cos_max is the one of the feature which is being set. */
> +list_for_each_entry(feat, &info->feat_list, list)
> +{
> +if ( feat->feature != feat_type )
> +continue;
> +
> +cos_max = feat->ops.get_cos_max(feat);
> +if ( cos_max > 0 )
What's the purpose of this check? I.e. why do you continue the loop
in case you find zero? You won't find another node with the same
feat_type, will you?
> +break;
> +}
> +
> +for ( cos = 0; cos <= cos_max; cos++ )
> +{
> +if ( cos && !ref[cos] )
> +continue;
> +
> +/* Not found, need find again from beginning. */
You may not even have looked yet, so how can you say "not found"?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 106555: tolerable trouble: broken/fail/pass - PUSHED
flight 106555 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106555/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen-buildfail never pass
build-arm64-pvops 5 kernel-build fail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 4cb22710d42a425b811fab622ced8ec622858116
baseline version:
xen f9adc1e66098e96861af49ca2d5a223ad654dec6
Last test of basis 106551 2017-03-08 14:17:10 Z0 days
Testing same since 106555 2017-03-08 16:02:02 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Christoph Egger
Haozhong Zhang
Jan Beulich
jobs:
build-amd64 pass
build-arm64 fail
build-armhf pass
build-amd64-libvirt pass
build-arm64-pvopsfail
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm broken
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 :
+ branch=xen-unstable-smoke
+ revision=4cb22710d42a425b811fab622ced8ec622858116
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
4cb22710d42a425b811fab622ced8ec622858116
+ branch=xen-unstable-smoke
+ revision=4cb22710d42a425b811fab622ced8ec622858116
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x4cb22710d42a425b811fab622ced8ec622858116 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xe
Re: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t
On 03/08/2017 08:49 AM, Reshetova, Elena wrote: >> On 03/06/2017 09:21 AM, Elena Reshetova wrote: >>> refcount_t type and corresponding API should be >>> used instead of atomic_t when the variable is used as >>> a reference counter. This allows to avoid accidental >>> refcounter overflows that might lead to use-after-free >>> situations. >>> >>> Signed-off-by: Elena Reshetova >>> Signed-off-by: Hans Liljestrand >>> Signed-off-by: Kees Cook >>> Signed-off-by: David Windsor >>> --- >>> drivers/xen/gntdev.c | 11 ++- >>> 1 file changed, 6 insertions(+), 5 deletions(-) >> Reviewed-by: Boris Ostrovsky > Is there a tree that can take this change? Turns out it is better to > propagate changes via separate trees and only leftovers can be taken via > Greg's tree. > Sure, we can take it via Xen tree for rc3. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 6/6] xen/arm: Remove dependency on __LINE__ for release builds
When using LivePatch, use of __LINE__ can generate spurious changes in
functions due to embedded line numbers. For release builds with
LivePatch enabled, remove the use of these line numbers and print the
current text address instead.
Signed-off-by: Ross Lagerwall
---
xen/arch/arm/traps.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 614501f..059afe7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -82,14 +82,28 @@ static inline void check_stack_alignment_constraints(void) {
* Compared with regular BUG_ON it dumps the guest vcpu state instead
* of Xen's state.
*/
+#if defined(NDEBUG) && defined(CONFIG_LIVEPATCH)
+#define guest_bug_on_failed(p) \
+do {\
+panic("Guest Bug: %pv: '%s', address %pS\n",\
+ current, p, current_text_addr()); \
+} while (0)
+#else
#define guest_bug_on_failed(p) \
do {\
-show_execution_state(guest_cpu_user_regs());\
panic("Guest Bug: %pv: '%s', line %d, file %s\n", \
current, p, __LINE__, __FILE__); \
} while (0)
-#define GUEST_BUG_ON(p) \
-do { if ( unlikely(p) ) guest_bug_on_failed(#p); } while (0)
+#endif
+
+#define GUEST_BUG_ON(p) \
+do {\
+if ( unlikely(p) ) \
+{ \
+show_execution_state(guest_cpu_user_regs());\
+guest_bug_on_failed(#p);\
+} \
+} while (0)
#ifdef CONFIG_ARM_32
static int debug_stack_lines = 20;
--
2.7.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/6] mm: Use statically defined locking order
Instead of using a locking order based on line numbers which interacts
poorly with trying to create a live patch, statically define the locking
order.
Signed-off-by: Ross Lagerwall
Reviewed-by: Dario Faggioli
---
Changes in v2:
* Rearranged defines.
* Make lock orders fit in a sign-extended 8-bit immediate.
xen/arch/x86/mm/mm-locks.h | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 74fdfc1..e5fceb2 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -46,8 +46,10 @@ static inline int mm_locked_by_me(mm_lock_t *l)
return (l->lock.recurse_cpu == current->processor);
}
-/* If you see this crash, the numbers printed are lines in this file
- * where the offending locks are declared. */
+/*
+ * If you see this crash, the numbers printed are order levels defined
+ * in this file.
+ */
#define __check_lock_level(l) \
do {\
if ( unlikely(__get_lock_level() > (l)) ) \
@@ -152,12 +154,12 @@ static inline void mm_read_unlock(mm_rwlock_t *l)
/* This wrapper uses the line number to express the locking order below */
#define declare_mm_lock(name) \
static inline void mm_lock_##name(mm_lock_t *l, const char *func, int rec)\
-{ _mm_lock(l, func, __LINE__, rec); }
+{ _mm_lock(l, func, MM_LOCK_ORDER_##name, rec); }
#define declare_mm_rwlock(name) \
static inline void mm_write_lock_##name(mm_rwlock_t *l, const char *func) \
-{ _mm_write_lock(l, func, __LINE__); }\
+{ _mm_write_lock(l, func, MM_LOCK_ORDER_##name); }
\
static inline void mm_read_lock_##name(mm_rwlock_t *l)\
-{ _mm_read_lock(l, __LINE__); }
+{ _mm_read_lock(l, MM_LOCK_ORDER_##name); }
/* These capture the name of the calling function */
#define mm_lock(name, l) mm_lock_##name(l, __func__, 0)
#define mm_lock_recursive(name, l) mm_lock_##name(l, __func__, 1)
@@ -169,10 +171,10 @@ static inline void mm_read_unlock(mm_rwlock_t *l)
* to ordering constraints. */
#define declare_mm_order_constraint(name) \
static inline void mm_enforce_order_lock_pre_##name(void) \
-{ _mm_enforce_order_lock_pre(__LINE__); } \
+{ _mm_enforce_order_lock_pre(MM_LOCK_ORDER_##name); }
\
static inline void mm_enforce_order_lock_post_##name( \
int *unlock_level, unsigned short *recurse_count) \
-{ _mm_enforce_order_lock_post(__LINE__, unlock_level, recurse_count); } \
+{ _mm_enforce_order_lock_post(MM_LOCK_ORDER_##name, unlock_level,
recurse_count); } \
static inline void mm_unlock(mm_lock_t *l)
{
@@ -201,8 +203,8 @@ static inline void mm_enforce_order_unlock(int unlock_level,
/
* *
- * To avoid deadlocks, these locks _MUST_ be taken in the order they're *
- * declared in this file. The locking functions will enforce this. *
+ * To avoid deadlocks, these locks _MUST_ be taken in the order listed *
+ * below. The locking functions will enforce this. *
* *
/
@@ -214,6 +216,7 @@ static inline void mm_enforce_order_unlock(int unlock_level,
* - setting the "cr3" field of any p2m table to a non-P2M_BASE_EAADR value.
* (i.e. assigning a p2m table to be the shadow of that cr3 */
+#define MM_LOCK_ORDER_nestedp2m 8
declare_mm_lock(nestedp2m)
#define nestedp2m_lock(d) mm_lock(nestedp2m, &(d)->arch.nested_p2m_lock)
#define nestedp2m_unlock(d) mm_unlock(&(d)->arch.nested_p2m_lock)
@@ -240,6 +243,7 @@ declare_mm_lock(nestedp2m)
* the altp2mlist lock in the middle.
*/
+#define MM_LOCK_ORDER_p2m16
declare_mm_rwlock(p2m);
/* Sharing per page lock
@@ -251,6 +255,7 @@ declare_mm_rwlock(p2m);
*
* The lock is recursive because during share we lock two pages. */
+#define MM_LOCK_ORDER_per_page_sharing 24
declare_mm_order_constraint(per_page_sharing)
#define page_sharing_mm_pre_lock()
mm_enforce_order_lock_pre_per_page_sharing()
#define page_sharing_mm_post_lock(l, r) \
@@ -265,6 +270,7 @@ declare_mm_order_constraint(per_page_sharing)
* in the target domain must be paused.
*/
+#define MM_LOCK_ORDER_altp2mlist 32
declare_mm_lock(altp2mlist)
#define altp2m_list_lock(d) mm_lock(altp2mlist, &(d)->arch.altp2m_list_lock)
#define altp2m_list_unlock(d) mm_unlock(
