Re: [Xen-devel] [PATCH 1/4] xen: sched: honour generic perf conuters in the RTDS scheduler
Not sure if I should comment with Reviewed-by, I will just do it. Please just ignore if I should not add Reviewed-by. 2015-02-26 8:36 GMT-05:00 Dario Faggioli dario.faggi...@citrix.com: more specifically, about vCPU initialization and destruction events, in line with adb26c09f26e (xen: sched: introduce a couple of counters in credit2 and SEDF). Signed-off-by: Dario Faggioli dario.faggi...@citrix.com Cc: Meng Xu xumengpa...@gmail.com Cc: George Dunlap george.dun...@eu.citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Keir Fraser k...@xen.org --- xen/common/sched_rt.c |4 1 file changed, 4 insertions(+) diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c index df4adac..58dd646 100644 --- a/xen/common/sched_rt.c +++ b/xen/common/sched_rt.c @@ -525,6 +525,8 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcpu *vc, void *dd) if ( !is_idle_vcpu(vc) ) svc-budget = RTDS_DEFAULT_BUDGET; +SCHED_STAT_CRANK(vcpu_init); + return svc; } @@ -574,6 +576,8 @@ rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc) struct rt_dom * const sdom = svc-sdom; spinlock_t *lock; +SCHED_STAT_CRANK(vcpu_destroy); + BUG_ON( sdom == NULL ); lock = vcpu_schedule_lock_irq(vc); Reviewed-by: Meng Xu men...@cis.upenn.edu Thanks, Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.16 test] 35326: regressions - FAIL
flight 35326 linux-3.16 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35326/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 15 guest-localmigrate/x10fail REGR. vs. 34167 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 34167 Tests which are failing intermittently (not blocking): test-amd64-i386-rumpuserxen-i386 8 guest-start fail pass in 34793 test-amd64-amd64-libvirt 9 guest-start fail pass in 34793 test-amd64-amd64-xl-pvh-intel 5 xen-boot fail in 34793 pass in 35326 test-amd64-i386-rhel6hvm-intel 5 xen-boot fail in 34793 pass in 35326 test-amd64-amd64-xl-sedf 3 host-install(3) broken in 34793 pass in 35326 test-amd64-i386-freebsd10-amd64 5 xen-bootfail in 34793 pass in 35326 test-amd64-i386-xl-qemut-win7-amd64 5 xen-bootfail in 34793 pass in 35326 test-amd64-i386-xl-winxpsp3 5 xen-boot fail in 34793 pass in 35326 test-amd64-i386-pair 8 xen-boot/dst_host fail in 34793 pass in 35326 test-amd64-i386-pair 7 xen-boot/src_host fail in 34793 pass in 35326 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels/;.repeat fail in 34793 blocked in 34167 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-amd64-i386-freebsd10-i386 7 freebsd-install fail never pass test-amd64-amd64-xl-multivcpu 15 guest-localmigrate/x10 fail never pass test-amd64-amd64-xl-sedf 15 guest-localmigrate/x10 fail never pass test-amd64-i386-freebsd10-amd64 7 freebsd-install fail never pass test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10 fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-libvirt 10 migrate-support-check fail in 34793 never pass version targeted for testing: linux4ba6745b95608891fdec154f6e75479e15a8a24e baseline version: linux19583ca584d6f574384e17fe7613dfaeadcdc4a6 1040 people touched revisions under test, not listing them all jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvops
Re: [Xen-devel] RFC: xen config changes v4
On 02/26/2015 06:42 PM, Stefano Stabellini wrote: On Thu, 26 Feb 2015, Luis R. Rodriguez wrote: On Thu, Feb 26, 2015 at 11:08:20AM +, Stefano Stabellini wrote: On Thu, 26 Feb 2015, David Vrabel wrote: On 26/02/15 04:59, Juergen Gross wrote: So we are again in the situation that pv-drivers always imply the pvops kernel (PARAVIRT selected). I started the whole Kconfig rework to eliminate this dependency. Yes. Can you produce a series that just addresses this one issue. In the absence of any concrete requirement for this big Kconfig reorg I I don't think it is helpful. I clearly missed some context as I didn't realize that this was the intended goal. Why do we want this? Please explain as it won't come for free. We have a few PV interfaces for HVM guests that need PARAVIRT in Linux in order to be used, for example pv_time_ops and HVMOP_pagetable_dying. They are critical performance improvements and from the interface perspective, small enough that doesn't make much sense having a separate KConfig option for them. In order to reach the goal above we necessarily need to introduce a differentiation in terms of PV on HVM guests in Linux: 1) basic guests with PV network, disk, etc but no PV timers, no HVMOP_pagetable_dying, no PV IPIs 2) full PV on HVM guests that have PV network, disk, timers, HVMOP_pagetable_dying, PV IPIs and anything else that makes sense. 2) is much faster than 1) on Xen and 2) is only a tiny bit slower than 1) on native x86 Also don't we shove 2) down hvm guests right now? Even when everything is built in I do not see how we opt out for HVM for 1) at run time right now. If this is true then the question of motivation for this becomes even stronger I think. Yes, indeed there is no way to do 1) at the moment. And for good reasons, see above. Hmm, after checking the code I'm not convinced: - HVMOP_pagetable_dying is obsolete on modern hardware supporting EPT/HAP - PV IPIs are not needed on single-vcpu guests - PARAVIRT_CLOCK doesn't need PARAVIRT (in fact the SUSEs kernel configs for all x86_64 kernels have CONFIG_PARAVIRT_CLOCK=y) So I think we really should enable building Xen frontends without PARAVIRT, implying at least no XEN_PV and no XEN_PVH. I'll have a try setting up patches. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] xen: sched: make counters for vCPU tickling generic
2015-02-26 8:37 GMT-05:00 Dario Faggioli dario.faggi...@citrix.com: and update them from Credit2 and RTDS schedulers. Signed-off-by: Dario Faggioli dario.faggi...@citrix.com Cc: Meng Xu xumengpa...@gmail.com Cc: George Dunlap george.dun...@eu.citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Keir Fraser k...@xen.org --- xen/common/sched_credit2.c |2 ++ xen/common/sched_rt.c|2 ++ xen/include/xen/perfc_defn.h |4 ++-- 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c index 2b852cc..bf13a84 100644 --- a/xen/common/sched_credit2.c +++ b/xen/common/sched_credit2.c @@ -571,9 +571,11 @@ tickle: (unsigned char *)d); } cpumask_set_cpu(ipid, rqd-tickled); +SCHED_STAT_CRANK(tickle_idlers_some); cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ); no_tickle: +SCHED_STAT_CRANK(tickle_idlers_none); return; } diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c index 49d1b83..2ad0c68 100644 --- a/xen/common/sched_rt.c +++ b/xen/common/sched_rt.c @@ -929,6 +929,7 @@ runq_tickle(const struct scheduler *ops, struct rt_vcpu *new) } /* didn't tickle any cpu */ +SCHED_STAT_CRANK(tickle_idlers_none); return; out: /* TRACE */ @@ -944,6 +945,7 @@ out: } cpumask_set_cpu(cpu_to_tickle, prv-tickled); +SCHED_STAT_CRANK(tickle_idlers_some); cpu_raise_softirq(cpu_to_tickle, SCHEDULE_SOFTIRQ); return; } The change for RTDS scheduler looks good to me. Thanks, Meng -- --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [v2][PATCH] libxl: add one machine property to support IGD GFX passthrough
On 2015/2/27 0:17, Ian Campbell wrote:
On Thu, 2015-02-26 at 14:35 +0800, Chen, Tiejun wrote:
If we are going to do this then I think we need to arrange for the
interface to be able to express the need to force the workarounds for a
particular device. IOW a boolean will not suffice since it doesn't
indicate that IGD workarounds are needed.
Probably it would be simplest to just leave this functionality out for
the time being and revisit if/when maintaining the list becomes an
annoyance or an end user trips over it.
You mean we should maintain one list to save all targeted devices, then
tools uses ids as an index to lookup this list to pass something to qemu.
I (think I) meant a list of pci vid:did in libxl, which is matched
against the devices passed to the domain (e.g. pci = [...] in xl cfg),
which then enables the igd workarounds, i.e. by passing the option to
Yeah, this is exactly what I'm understanding.
qemu.
But actually one question that I have always been thinking about is, its
really a responsibility of Xen to determine which device type should be
passed by probing that pair of vendor and device ids? Xen is just one of
so many approaches to qemu so such a rare workaround option can be
passed actively by any user, instead of Xen. Furthermore, its becoming
flexible as well to those cases we want to force overriding this.
I'm not sure, but I think you are suggestion that qemu should autodetect
this situation, without being explicitly told igd-passthru=on on the
command line?
If the qemu maintainers are amenable to that, and it's not already the
case that other components (e.g. hvmloader) need to be told about these
workarounds, then I suppose that would work.
So I think qemu should mainly plays this role. If qemu realizes we're
passing through a IGD or other targeted device, it should post a warning
or even error message to indicate what right behavior is needed, or what
is that potential risk by default.
Hrm, here it sounds more like you are suggesting that qemu should detect
and warn, rather than detect and do the right thing?
I'm not sure how Qemu could indicate what the right behaviour is going
to be, it'll differ for different hypervisors or even for which Xen
toolstack (xl vs libvirt etc) is in use.
Or maybe I've misunderstood?
IGD is a tricky case since Qemu has to construct a ISA bridge and host
bridge before we pass IGD device. But we don't like to expose these two
bridges unconditionally, and this is also why we need this option.
Here I just mean when Qemu realizes IGD is passed through but without
that appropriate option set, Qemu can post something to explicitly
notify user that this option is needed in his case. But it may be a lazy
idea.
So now I think I'd better go back handling this on Xen side with your
comments. As you said the Boolean doesn't suffice to indicate that IGD
workarounds are needed. So I think we can reuse that existing bool
'gfx_passthru'.
Firstly we can redefine this as string,
- (gfx_passthru, libxl_defbool),
+ (gfx_passthru, string),
Then
+
+if (libxl__is_igd_vga_passthru(gc, guest_config) ||
+(b_info-u.hvm.gfx_passthru
+ strncmp(b_info-u.hvm.gfx_passthru, igd, 3) == 0) ) {
+machinearg = GCSPRINTF(%s,igd-passthru=on, machinearg);
+}
+
Of course we need modify something else to align this change.
Thanks
Tiejun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [rumpuserxen test] 35525: regressions - FAIL
flight 35525 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35525/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen 21909666eb2d85c02770d04691795abfd4417392 baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Antti Kantee po...@iki.fi Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net jobs: build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 339 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: xen config changes v4
On 02/26/2015 07:48 PM, Luis R. Rodriguez wrote: On Thu, Feb 26, 2015 at 05:42:57PM +, Stefano Stabellini wrote: On Thu, 26 Feb 2015, Luis R. Rodriguez wrote: On Thu, Feb 26, 2015 at 11:08:20AM +, Stefano Stabellini wrote: On Thu, 26 Feb 2015, David Vrabel wrote: On 26/02/15 04:59, Juergen Gross wrote: So we are again in the situation that pv-drivers always imply the pvops kernel (PARAVIRT selected). I started the whole Kconfig rework to eliminate this dependency. Yes. Can you produce a series that just addresses this one issue. In the absence of any concrete requirement for this big Kconfig reorg I I don't think it is helpful. I clearly missed some context as I didn't realize that this was the intended goal. Why do we want this? Please explain as it won't come for free. We have a few PV interfaces for HVM guests that need PARAVIRT in Linux in order to be used, for example pv_time_ops and HVMOP_pagetable_dying. They are critical performance improvements and from the interface perspective, small enough that doesn't make much sense having a separate KConfig option for them. In order to reach the goal above we necessarily need to introduce a differentiation in terms of PV on HVM guests in Linux: 1) basic guests with PV network, disk, etc but no PV timers, no HVMOP_pagetable_dying, no PV IPIs 2) full PV on HVM guests that have PV network, disk, timers, HVMOP_pagetable_dying, PV IPIs and anything else that makes sense. 2) is much faster than 1) on Xen and 2) is only a tiny bit slower than 1) on native x86 Also don't we shove 2) down hvm guests right now? Even when everything is built in I do not see how we opt out for HVM for 1) at run time right now. If this is true then the question of motivation for this becomes even stronger I think. Yes, indeed there is no way to do 1) at the moment. And for good reasons, see above. OK if the goal is to be able to build front end drivers by avoiding building PARAVIRT / PARAVIRT_CLOCK and if the gains to be able to do so (which haven't been stated other than just the ability to do so) are small (as Stefano notes simple hvm containers do not perform great) but requires a bit of work, I'd rather ask -- why not address *why* we are avoiding PARAVIRT / PARAVIRT_CLOCK and stick to the original goals behind the pvops model by addressing what is required to be able to continue to be happy with one single kernel. The work required to do that might be more than to just be able to build simple Xen hvm containers without PARAVIRT / PARAVIRT_CLOCK but I'd think the gains would be much higher. I absolutely agree. I think this is a long term goal we should work on. PVH should address most of the issues, BTW. If this resonates well then I'd like to ask: what are the current most pressing issues with enabling PARAVIRT / PARAVIRT_CLOCK. PARAVIRT: performance, especially memory management PARAVIRT_CLOCK: none Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] When to use domain creation flag or HVM param?
Tim, Andrew, Jan, it seems as if we are slowly coming to some conclusion on this thread. If I am mistaken, I am wondering whether it would make sense to have an IRC meeting with all the involved stake-holders and report back to the list. Regards Lars On 26/02/2015 10:52, Tim Deegan t...@xen.org wrote: At 10:50 + on 24 Feb (1424771408), Andrew Cooper wrote: On 24/02/15 10:31, Jan Beulich wrote: On 24.02.15 at 11:24, t...@xen.org wrote: At 15:08 -0500 on 23 Feb (1424700515), Don Slutz wrote: Currently Jan Beulich is not happy with the addition of a new domain creation flag. Andrew Cooper is not happy with a HVM param. I am stuck in the middle. I prefer a new flag, for anything that's fixed for the life of the domain. We've already had too many bugs where HVM params changed when people thought they wouldn't. Jan, is your objection that we'll run out of XEN_DOMCTL_CDF_* bits? I think we can add more flag fields to DOMCTL_createdomain (or a v2) if that becomes a problem. In a couple of years we may end up with an x86-CPUID-like mess of hundreds of flags. And apart from that scalability issue I also dislike the gross mixing of arch specific and generic flags here. Perhaps the already arch-specific XEN_DOMCTL_configure_domain would be the better route then if HVM params are being disliked? Given some recent consideration to the problem of domain architectural state (x86 cpuid policy, arm gic/spi), a (set of?) configuration hypercalls valid only during domain construction would perhaps be the best way to proceed. That sounds like you're also arguing for using HVM params then. :) The nice thing about having a single set of flags at creation time is that it avoids any worrying about what order the flag-setting and the init of VM state happens in (e.g. turning on a feature after vcpus are already assigned means extra code to update them; having the features be settable in any order means handling all O(N^2) interactions). Extending createdomain itself is incompatible with XSM disaggregation Hrm. Possibly, but I think that might be splitting hairs. A privileged VM creation component will already have to check its arguments (e.g. memory size, #vcpus, boot image) against some policy. and having the architectural state in the migration stream. Not at all -- since these flags are immutable, you can trivially send them before any other state. If a toolstack can't remember what it did, we could add a what-were-the-creation-flags domctl. Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5: can't create DomU guest on mustang(arm64)
On Thu, 2015-02-26 at 11:55 +0800, Ming Lei wrote: libxl: error: libxl_device.c:950:device_backend_callback: unable to add device with path /local/domain/0/backend/vbd/4/51712 libxl: error: libxl_create.c:1153:domcreate_launch_dm: unable to add disk devices libxl: error: libxl_device.c:950:device_backend_callback: unable to remove device with path /local/domain/0/backend/vbd/4/51712 libxl: error: libxl.c:1640:devices_destroy_cb: libxl__devices_destroy failed for 4 This makes me think that either your kernel does not have blkback enabled or the module is not loaded. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] RFC: Make xen's public headers a little friendlier for C++.
Shuffle some struct definitions up to file scope so that they remain
in scope in C++ when they're used again later.
Add an automatic check for similar C++ pitfalls, to be run only when
g++ is available.
RFC because it's not clear whether we want to make any commitments to
have the public headers be C++-friendly.
Explicitly _not_ addressing the use of 'private' in various fields,
since we'd previously decided not to fix that.
Reported-by: Razvan Cojocaru rcojoc...@bitdefender.com
Signed-off-by: Tim Deegan t...@xen.org
Cc: Jan Beulich jbeul...@suse.com
---
.gitignore| 1 +
xen/include/Makefile | 12 +---
xen/include/public/platform.h | 39 ++-
3 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/.gitignore b/.gitignore
index 13ee05b..78958ea 100644
--- a/.gitignore
+++ b/.gitignore
@@ -233,6 +233,7 @@ xen/arch/*/efi/compat.c
xen/arch/*/efi/efi.h
xen/arch/*/efi/runtime.c
xen/include/headers.chk
+xen/include/headers++.chk
xen/include/asm
xen/include/asm-*/asm-offsets.h
xen/include/compat/*
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 94112d1..c361877 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -87,13 +87,19 @@ compat/xlat.h: $(addprefix compat/.xlat/,$(xlat-y)) Makefile
ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
-all: headers.chk
+all: headers.chk headers++.chk
-headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/%
public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) Makefile
+PUBLIC_HEADERS_TO_CHECK := $(filter-out public/arch-% public/%ctl.h
public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h)
$(public-y))
+
+headers.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile
for i in $(filter %.h,$^); do $(CC) -ansi -include stdint.h -Wall -W
-Werror -S -o /dev/null -x c $$i || exit 1; echo $$i; done $@.new
mv $@.new $@
+headers++.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile
+ if g++ -v /dev/null; then for i in $(filter %.h,$^); do g++ -ansi
-include stdint.h -Wall -W -Werror -S -o /dev/null -x c++
-Dprivate=private_is_a_keyword_in_c_plus_plus $$i || exit 1; echo $$i; done ;
fi $@.new
+ mv $@.new $@
+
endif
clean::
- rm -rf compat headers.chk
+ rm -rf compat headers.chk headers++.chk
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 3e340b4..dd03447 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -126,6 +126,26 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_platform_quirk_t);
#define XEN_EFI_query_variable_info 9
#define XEN_EFI_query_capsule_capabilities 10
#define XEN_EFI_update_capsule 11
+
+struct xenpf_efi_guid {
+uint32_t data1;
+uint16_t data2;
+uint16_t data3;
+uint8_t data4[8];
+};
+
+struct xenpf_efi_time {
+uint16_t year;
+uint8_t month;
+uint8_t day;
+uint8_t hour;
+uint8_t min;
+uint8_t sec;
+uint32_t ns;
+int16_t tz;
+uint8_t daylight;
+};
+
struct xenpf_efi_runtime_call {
uint32_t function;
/*
@@ -138,17 +158,7 @@ struct xenpf_efi_runtime_call {
union {
#define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x0001
struct {
-struct xenpf_efi_time {
-uint16_t year;
-uint8_t month;
-uint8_t day;
-uint8_t hour;
-uint8_t min;
-uint8_t sec;
-uint32_t ns;
-int16_t tz;
-uint8_t daylight;
-} time;
+struct xenpf_efi_time time;
uint32_t resolution;
uint32_t accuracy;
} get_time;
@@ -170,12 +180,7 @@ struct xenpf_efi_runtime_call {
XEN_GUEST_HANDLE(void) name; /* UCS-2/UTF-16 string */
xen_ulong_t size;
XEN_GUEST_HANDLE(void) data;
-struct xenpf_efi_guid {
-uint32_t data1;
-uint16_t data2;
-uint16_t data3;
-uint8_t data4[8];
-} vendor_guid;
+struct xenpf_efi_guid vendor_guid;
} get_variable, set_variable;
struct {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: xen config changes v4
On 26/02/15 04:59, Juergen Gross wrote: So we are again in the situation that pv-drivers always imply the pvops kernel (PARAVIRT selected). I started the whole Kconfig rework to eliminate this dependency. Yes. Can you produce a series that just addresses this one issue. In the absence of any concrete requirement for this big Kconfig reorg I I don't think it is helpful. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 19/23] libxlu: nested list support
1. Extend grammar of parser.
2. Adjust internal functions to accept XLU_ConfigValue instead of
char *.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxl/libxlu_cfg.c | 30 +++---
tools/libxl/libxlu_cfg_i.h | 5 +++--
tools/libxl/libxlu_cfg_y.c | 26 +-
tools/libxl/libxlu_cfg_y.y | 4 ++--
4 files changed, 25 insertions(+), 40 deletions(-)
diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index f000eed..611f5ec 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -332,19 +332,14 @@ XLU_ConfigValue *xlu__cfg_string_mk(CfgParseContext *ctx,
char *atom)
return NULL;
}
-XLU_ConfigValue *xlu__cfg_list_mk(CfgParseContext *ctx, char *atom)
+XLU_ConfigValue *xlu__cfg_list_mk(CfgParseContext *ctx,
+ XLU_ConfigValue *val)
{
XLU_ConfigValue *value = NULL;
XLU_ConfigValue **values = NULL;
-XLU_ConfigValue *val = NULL;
if (ctx-err) goto x;
-val = malloc(sizeof(*val));
-if (!val) goto xe;
-val-type = XLU_STRING;
-val-u.string = atom;
-
values = malloc(sizeof(*values));
if (!values) goto xe;
values[0] = val;
@@ -363,19 +358,17 @@ XLU_ConfigValue *xlu__cfg_list_mk(CfgParseContext *ctx,
char *atom)
x:
free(value);
free(values);
-free(val);
-free(atom);
+xlu__cfg_value_free(val);
return NULL;
}
void xlu__cfg_list_append(CfgParseContext *ctx,
XLU_ConfigValue *list,
- char *atom)
+ XLU_ConfigValue *val)
{
-XLU_ConfigValue *val = NULL;
if (ctx-err) return;
-assert(atom);
+assert(val);
assert(list-type == XLU_LIST);
if (list-u.list.nvalues = list-u.list.avalues) {
@@ -384,7 +377,7 @@ void xlu__cfg_list_append(CfgParseContext *ctx,
if (list-u.list.avalues INT_MAX / 100) {
ctx-err = ERANGE;
-free(atom);
+xlu__cfg_value_free(val);
return;
}
@@ -393,7 +386,7 @@ void xlu__cfg_list_append(CfgParseContext *ctx,
sizeof(*new_values) * new_avalues);
if (!new_values) {
ctx-err = errno;
-free(atom);
+xlu__cfg_value_free(val);
return;
}
@@ -401,15 +394,6 @@ void xlu__cfg_list_append(CfgParseContext *ctx,
list-u.list.values = new_values;
}
-val = malloc(sizeof(*val));
-if (!val) {
-ctx-err = errno;
-free(atom);
-return;
-}
-
-val-type = XLU_STRING;
-val-u.string = atom;
list-u.list.values[list-u.list.nvalues] = val;
list-u.list.nvalues++;
}
diff --git a/tools/libxl/libxlu_cfg_i.h b/tools/libxl/libxlu_cfg_i.h
index b71e9fd..11dc33f 100644
--- a/tools/libxl/libxlu_cfg_i.h
+++ b/tools/libxl/libxlu_cfg_i.h
@@ -27,10 +27,11 @@ void xlu__cfg_set_store(CfgParseContext*, char *name,
XLU_ConfigValue *val, int lineno);
XLU_ConfigValue *xlu__cfg_string_mk(CfgParseContext *ctx,
char *atom);
-XLU_ConfigValue *xlu__cfg_list_mk(CfgParseContext *ctx, char *atom);
+XLU_ConfigValue *xlu__cfg_list_mk(CfgParseContext *ctx,
+ XLU_ConfigValue *val);
void xlu__cfg_list_append(CfgParseContext *ctx,
XLU_ConfigValue *list,
- char *atom);
+ XLU_ConfigValue *val);
void xlu__cfg_value_free(XLU_ConfigValue *value);
char *xlu__cfgl_strdup(CfgParseContext*, const char *src);
char *xlu__cfgl_dequote(CfgParseContext*, const char *src);
diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c
index eb3884f..b05e48b 100644
--- a/tools/libxl/libxlu_cfg_y.c
+++ b/tools/libxl/libxlu_cfg_y.c
@@ -377,7 +377,7 @@ union yyalloc
/* YYFINAL -- State number of the termination state. */
#define YYFINAL 3
/* YYLAST -- Last index in YYTABLE. */
-#define YYLAST 24
+#define YYLAST 25
/* YYNTOKENS -- Number of terminals. */
#define YYNTOKENS 12
@@ -444,8 +444,8 @@ static const yytype_int8 yyrhs[] =
15,-1,16,17,-1,17,-1, 1, 6,-1,
3, 7,18,-1, 6,-1, 8,-1,19,-1,
9,22,20,10,-1, 4,-1, 5,-1,-1,
- 21,-1,21,11,22,-1,19,22,-1,21,
- 11,22,19,22,-1,-1,22, 6,-1
+ 21,-1,21,11,22,-1,18,22,-1,21,
+ 11,22,18,22,-1,-1,22, 6,-1
};
/* YYRLINE[YYN] -- source line where rule number YYN was defined. */
@@ -517,14 +517,14 @@ static const yytype_int8 yydefgoto[] =
static const yytype_int8 yypact[] =
{
-18, 4,
[Xen-devel] [PATCH v6 17/23] libxl: define LIBXL_HAVE_VNUMA
Signed-off-by: Wei Liu wei.l...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com --- Changes in v6: 1. Better description of the macro. --- tools/libxl/libxl.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index c219f59..c668c04 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -67,6 +67,13 @@ * the same $(XEN_VERSION) (e.g. throughout a major release). */ +/* LIBXL_HAVE_VNUMA + * + * If this is defined the type libxl_vnode_info exists, and a + * field 'vnuma_nodes' is present in libxl_domain_build_info. + */ +#define LIBXL_HAVE_VNUMA 1 + /* LIBXL_HAVE_USERDATA_UNLINK * * If it is defined, libxl has a library function called -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 21/23] libxlu: introduce new APIs
These APIs can be used to manipulate XLU_ConfigValue and XLU_ConfigList.
APIs introduced:
1. xlu_cfg_value_type
2. xlu_cfg_value_get_string
3. xlu_cfg_value_get_list
4. xlu_cfg_get_listitem2
Move some definitions from private header to public header as needed.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
---
Changes in v6:
1. Report value's line and column number on error.
Changes in v5:
1. Use calling convention like old APIs.
---
tools/libxl/libxlu_cfg.c | 45 +++
tools/libxl/libxlu_internal.h | 7 ---
tools/libxl/libxlutil.h | 13 +
3 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index b921a13..62fb798 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -199,6 +199,51 @@ static int find_atom(const XLU_Config *cfg, const char *n,
return 0;
}
+
+enum XLU_ConfigValueType xlu_cfg_value_type(const XLU_ConfigValue *value)
+{
+return value-type;
+}
+
+int xlu_cfg_value_get_string(const XLU_Config *cfg, XLU_ConfigValue *value,
+ char **value_r, int dont_warn)
+{
+if (value-type != XLU_STRING) {
+if (!dont_warn)
+fprintf(cfg-report,
+%s:%d:%d: warning: value is not a string\n,
+cfg-config_source, value-line, value-column);
+*value_r = NULL;
+return EINVAL;
+}
+
+*value_r = value-u.string;
+return 0;
+}
+
+int xlu_cfg_value_get_list(const XLU_Config *cfg, XLU_ConfigValue *value,
+ XLU_ConfigList **value_r, int dont_warn)
+{
+if (value-type != XLU_LIST) {
+if (!dont_warn)
+fprintf(cfg-report,
+%s:%d:%d: warning: value is not a list\n,
+cfg-config_source, value-line, value-column);
+*value_r = NULL;
+return EINVAL;
+}
+
+*value_r = value-u.list;
+return 0;
+}
+
+XLU_ConfigValue *xlu_cfg_get_listitem2(const XLU_ConfigList *list,
+ int entry)
+{
+if (entry 0 || entry = list-nvalues) return NULL;
+return list-values[entry];
+}
+
int xlu_cfg_get_string(const XLU_Config *cfg, const char *n,
const char **value_r, int dont_warn) {
XLU_ConfigSetting *set;
diff --git a/tools/libxl/libxlu_internal.h b/tools/libxl/libxlu_internal.h
index 73fd85f..1d310b1 100644
--- a/tools/libxl/libxlu_internal.h
+++ b/tools/libxl/libxlu_internal.h
@@ -25,13 +25,6 @@
#include libxlutil.h
-enum XLU_ConfigValueType {
-XLU_STRING,
-XLU_LIST,
-};
-
-typedef struct XLU_ConfigValue XLU_ConfigValue;
-
typedef struct XLU_ConfigList {
int avalues; /* available slots */
int nvalues; /* actual occupied slots */
diff --git a/tools/libxl/libxlutil.h b/tools/libxl/libxlutil.h
index 0333e55..989605a 100644
--- a/tools/libxl/libxlutil.h
+++ b/tools/libxl/libxlutil.h
@@ -20,9 +20,15 @@
#include libxl.h
+enum XLU_ConfigValueType {
+XLU_STRING,
+XLU_LIST,
+};
+
/* Unless otherwise stated, all functions return an errno value. */
typedef struct XLU_Config XLU_Config;
typedef struct XLU_ConfigList XLU_ConfigList;
+typedef struct XLU_ConfigValue XLU_ConfigValue;
XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename);
/* 0 means we got ENOMEM. */
@@ -66,6 +72,13 @@ const char *xlu_cfg_get_listitem(const XLU_ConfigList*, int
entry);
/* xlu_cfg_get_listitem cannot fail, except that if entry is
* out of range it returns 0 (not setting errno) */
+enum XLU_ConfigValueType xlu_cfg_value_type(const XLU_ConfigValue *value);
+int xlu_cfg_value_get_string(const XLU_Config *cfg, XLU_ConfigValue *value,
+ char **value_r, int dont_warn);
+int xlu_cfg_value_get_list(const XLU_Config *cfg, XLU_ConfigValue *value,
+ XLU_ConfigList **value_r, int dont_warn);
+XLU_ConfigValue *xlu_cfg_get_listitem2(const XLU_ConfigList *list,
+ int entry);
/*
* Disk specification parsing.
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 18/23] libxlu: rework internal representation of setting
This patches does following things:
1. Properly define a XLU_ConfigList type. Originally it was defined to
be XLU_ConfigSetting.
2. Define XLU_ConfigValue type, which can be either a string or a list
of XLU_ConfigValue.
3. ConfigSetting now references XLU_ConfigValue. Originally it only
worked with **string.
4. Properly construct list where necessary, see changes to .y file.
To achieve above changes:
1. xlu__cfg_set_mk and xlu__cfg_set_add are deleted, because they
are no more needed in the new code.
2. Introduce xlu__cfg_string_mk to make a XLU_ConfigSetting that points
to a XLU_ConfigValue that wraps a string.
3. Introduce xlu__cfg_list_mk to make a XLU_ConfigSetting that points
to XLU_ConfigValue that is a list.
4. The parser now generates XLU_ConfigValue instead of XLU_ConfigSetting
when construct values, which enables us to recursively generate list
of lists.
5. XLU_ConfigSetting is generated in xlu__cfg_set_store.
6. Adapt other functions to use new types.
No change to public API. Xl compiles without problem and 'xl create -n
guest.cfg' is valgrind clean.
This patch is needed because we're going to implement nested list
support, which requires support for list of list.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
Changes in v5:
1. Use standard expanding-array pattern.
---
tools/libxl/libxlu_cfg.c | 170 ++
tools/libxl/libxlu_cfg_i.h| 12 ++-
tools/libxl/libxlu_cfg_y.c| 24 +++---
tools/libxl/libxlu_cfg_y.h| 2 +-
tools/libxl/libxlu_cfg_y.y| 14 ++--
tools/libxl/libxlu_internal.h | 30 ++--
6 files changed, 173 insertions(+), 79 deletions(-)
diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index 22adcb0..f000eed 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -131,14 +131,28 @@ int xlu_cfg_readdata(XLU_Config *cfg, const char *data,
int length) {
return ctx.err;
}
-void xlu__cfg_set_free(XLU_ConfigSetting *set) {
+void xlu__cfg_value_free(XLU_ConfigValue *value)
+{
int i;
+if (!value) return;
+
+switch (value-type) {
+case XLU_STRING:
+free(value-u.string);
+break;
+case XLU_LIST:
+for (i = 0; i value-u.list.nvalues; i++)
+xlu__cfg_value_free(value-u.list.values[i]);
+free(value-u.list.values);
+}
+free(value);
+}
+
+void xlu__cfg_set_free(XLU_ConfigSetting *set) {
if (!set) return;
free(set-name);
-for (i=0; iset-nvalues; i++)
-free(set-values[i]);
-free(set-values);
+xlu__cfg_value_free(set-value);
free(set);
}
@@ -173,7 +187,7 @@ static int find_atom(const XLU_Config *cfg, const char *n,
set= find(cfg,n);
if (!set) return ESRCH;
-if (set-avalues!=1) {
+if (set-value-type!=XLU_STRING) {
if (!dont_warn)
fprintf(cfg-report,
%s:%d: warning: parameter `%s' is
@@ -191,7 +205,7 @@ int xlu_cfg_get_string(const XLU_Config *cfg, const char *n,
int e;
e= find_atom(cfg,n,set,dont_warn); if (e) return e;
-*value_r= set-values[0];
+*value_r= set-value-u.string;
return 0;
}
@@ -202,7 +216,7 @@ int xlu_cfg_replace_string(const XLU_Config *cfg, const
char *n,
e= find_atom(cfg,n,set,dont_warn); if (e) return e;
free(*value_r);
-*value_r= strdup(set-values[0]);
+*value_r= strdup(set-value-u.string);
return 0;
}
@@ -214,7 +228,7 @@ int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
char *ep;
e= find_atom(cfg,n,set,dont_warn); if (e) return e;
-errno= 0; l= strtol(set-values[0], ep, 0);
+errno= 0; l= strtol(set-value-u.string, ep, 0);
e= errno;
if (errno) {
e= errno;
@@ -226,7 +240,7 @@ int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
cfg-config_source, set-lineno, n, strerror(e));
return e;
}
-if (*ep || ep==set-values[0]) {
+if (*ep || ep==set-value-u.string) {
if (!dont_warn)
fprintf(cfg-report,
%s:%d: warning: parameter `%s' is not a valid number\n,
@@ -253,7 +267,7 @@ int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
XLU_ConfigSetting *set;
set= find(cfg,n); if (!set) return ESRCH;
-if (set-avalues==1) {
+if (set-value-type!=XLU_LIST) {
if (!dont_warn) {
fprintf(cfg-report,
%s:%d: warning: parameter `%s' is a single value
@@ -262,8 +276,8 @@ int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
}
return EINVAL;
}
-if (list_r) *list_r= set;
-if (entries_r) *entries_r= set-nvalues;
+if (list_r) *list_r= set-value-u.list;
+if (entries_r) *entries_r=
[Xen-devel] [PATCH v6 03/23] xen: make two memory hypercalls vNUMA-aware
Make XENMEM_increase_reservation and XENMEM_populate_physmap
vNUMA-aware.
That is, if guest requests Xen to allocate memory for specific vnode,
Xen can translate vnode to pnode using vNUMA information of that guest.
XENMEMF_vnode is introduced for the guest to mark the node number is in
fact virtual node number and should be translated by Xen.
XENFEAT_memory_op_vnode_supported is introduced to indicate that Xen is
able to translate virtual node to physical node.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
---
Changes in v6:
1. Add logic in construct_memop_from_reservation.
---
xen/common/kernel.c | 2 +-
xen/common/memory.c | 45 ---
xen/include/public/features.h | 3 +++
xen/include/public/memory.h | 2 ++
4 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 0d9e519..e5e0050 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -301,7 +301,7 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
switch ( fi.submap_idx )
{
case 0:
-fi.submap = 0;
+fi.submap = (1U XENFEAT_memory_op_vnode_supported);
if ( VM_ASSIST(d, VMASST_TYPE_pae_extended_cr3) )
fi.submap |= (1U XENFEAT_pae_pgdir_above_4gb);
if ( paging_mode_translate(current-domain) )
diff --git a/xen/common/memory.c b/xen/common/memory.c
index d24b001..9f8891b 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -692,7 +692,7 @@ out:
return rc;
}
-static int construct_memop_from_reservation(
+static int construct_memop_from_reservation(struct domain *d,
const struct xen_memory_reservation *r,
struct memop_args *a)
{
@@ -716,9 +716,37 @@ static int construct_memop_from_reservation(
a-memflags = MEMF_bits(address_bits);
}
-a-memflags |= MEMF_node(XENMEMF_get_node(r-mem_flags));
-if ( r-mem_flags XENMEMF_exact_node_request )
-a-memflags |= MEMF_exact_node;
+if ( r-mem_flags XENMEMF_vnode )
+{
+unsigned int vnode, pnode;
+
+read_lock(d-vnuma_rwlock);
+if ( d-vnuma )
+{
+vnode = XENMEMF_get_node(r-mem_flags);
+if ( vnode = d-vnuma-nr_vnodes )
+{
+rc = -EINVAL;
+read_unlock(d-vnuma_rwlock);
+goto out;
+}
+
+pnode = d-vnuma-vnode_to_pnode[vnode];
+if ( pnode != XEN_NUMA_NO_NODE )
+{
+a-memflags |= MEMF_node(pnode);
+if ( r-mem_flags XENMEMF_exact_node_request )
+a-memflags |= MEMF_exact_node;
+}
+}
+read_unlock(d-vnuma_rwlock);
+}
+else
+{
+a-memflags |= MEMF_node(XENMEMF_get_node(r-mem_flags));
+if ( r-mem_flags XENMEMF_exact_node_request )
+a-memflags |= MEMF_exact_node;
+}
rc = 0;
out:
@@ -753,9 +781,6 @@ long do_memory_op(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
args.nr_done = start_extent;
args.preempted= 0;
-if ( construct_memop_from_reservation(reservation, args) )
-return start_extent;
-
if ( op == XENMEM_populate_physmap
(reservation.mem_flags XENMEMF_populate_on_demand) )
args.memflags |= MEMF_populate_on_demand;
@@ -765,6 +790,12 @@ long do_memory_op(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
return start_extent;
args.domain = d;
+if ( construct_memop_from_reservation(d, reservation, args) )
+{
+rcu_unlock_domain(d);
+return start_extent;
+}
+
if ( xsm_memory_adjust_reservation(XSM_TARGET, current-domain, d) )
{
rcu_unlock_domain(d);
diff --git a/xen/include/public/features.h b/xen/include/public/features.h
index 16d92aa..2110b04 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -99,6 +99,9 @@
#define XENFEAT_grant_map_identity12
*/
+/* Guest can use XENMEMF_vnode to specify virtual node for memory op. */
+#define XENFEAT_memory_op_vnode_supported 13
+
#define XENFEAT_NR_SUBMAPS 1
#endif /* __XEN_PUBLIC_FEATURES_H__ */
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index 0d8c85f..d71127f 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -57,6 +57,8 @@
/* Flag to request allocation only from the node specified */
#define XENMEMF_exact_node_request (117)
#define XENMEMF_exact_node(n) (XENMEMF_node(n) | XENMEMF_exact_node_request)
+/* Flag to indicate the node specified is virtual node */
+#define XENMEMF_vnode (118)
#endif
struct xen_memory_reservation {
--
1.9.1
___
Xen-devel mailing list
[Xen-devel] [PATCH v6 23/23] xl: vNUMA support
This patch includes configuration options parser and documentation.
Please find the hunk to xl.cfg.pod.5 for more information.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
Changes in v6:
1. Disable NUMA auto-placement.
---
docs/man/xl.cfg.pod.5| 54 ++
tools/libxl/xl_cmdimpl.c | 140 ++-
2 files changed, 193 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 408653f..2a27b1c 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -266,6 +266,60 @@ it will crash.
=back
+=head3 Guest Virtual NUMA Configuration
+
+=over 4
+
+=item Bvnuma=[ VNODE_SPEC, VNODE_SPEC, ... ]
+
+Specify virtual NUMA configuration with positional arguments. The
+nth BVNODE_SPECE in the list specifies the configuration of nth
+virtual node.
+
+Each BVNODE_SPEC is a list, which has a form of
+[VNODE_CONFIG_OPTION,VNODE_CONFIG_OPTION, ... ] (without quotes).
+
+For example vnuma = [ [pnode=0,size=512,vcpus=0-4,vdistances=10,20] ]
+means vnode 0 is mapped to pnode 0, has 512MB ram, has vcpus 0 to 4, the
+distance to itself is 10 and the distance to vnode 1 is 20.
+
+Each BVNODE_CONFIG_OPTION is a quoted string. Supported
+BVNODE_CONFIG_OPTIONs are:
+
+=over 4
+
+=item Bpnode=NUMBER
+
+Specify which physical node this virtual node maps to.
+
+=item Bsize=MBYTES
+
+Specify the size of this virtual node. The sum of memory size of all
+vnodes must match Bmaxmem= (or Bmemory= if Bmaxmem= is not
+specified).
+
+=item Bvcpus=CPU-STRING
+
+Specify which vcpus belong to this node. BCPU-STRING is a string
+separated by comma. You can specify range and single cpu. An example
+is vcpus=0-5,8, which means you specify vcpu 0 to vcpu 5, and vcpu
+8.
+
+=item Bvdistances=NUMBER, NUMBER, ...
+
+Specify virtual distance from this node to all nodes (including
+itself) with positional arguments. For example, vdistance=10,20
+for vnode 0 means the distance from vnode 0 to vnode 0 is 10, from
+vnode 0 to vnode 1 is 20. The number of arguments supplied must match
+the total number of vnodes.
+
+Normally you can use the values from xl info -n or numactl
+--hardware to fill in vdistance list.
+
+=back
+
+=back
+
=head3 Event Actions
=over 4
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 5b366f2..2899d9f 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -158,7 +158,6 @@ struct domain_create {
};
-static uint32_t find_domain(const char *p) __attribute__((warn_unused_result));
static uint32_t find_domain(const char *p)
{
uint32_t domid;
@@ -987,6 +986,143 @@ static int parse_nic_config(libxl_device_nic *nic,
XLU_Config **config, char *to
return 0;
}
+static void parse_vnuma_config(const XLU_Config *config,
+ libxl_domain_build_info *b_info)
+{
+libxl_physinfo physinfo;
+uint32_t nr_nodes;
+XLU_ConfigList *vnuma;
+int i, j, len, num_vnuma;
+
+
+libxl_physinfo_init(physinfo);
+if (libxl_get_physinfo(ctx, physinfo) != 0) {
+libxl_physinfo_dispose(physinfo);
+fprintf(stderr, libxl_get_physinfo failed\n);
+exit(1);
+}
+
+nr_nodes = physinfo.nr_nodes;
+libxl_physinfo_dispose(physinfo);
+
+if (xlu_cfg_get_list(config, vnuma, vnuma, num_vnuma, 1))
+return;
+
+b_info-num_vnuma_nodes = num_vnuma;
+b_info-vnuma_nodes = xcalloc(num_vnuma, sizeof(libxl_vnode_info));
+
+for (i = 0; i b_info-num_vnuma_nodes; i++) {
+libxl_vnode_info *p = b_info-vnuma_nodes[i];
+
+libxl_vnode_info_init(p);
+libxl_cpu_bitmap_alloc(ctx, p-vcpus, b_info-max_vcpus);
+libxl_bitmap_set_none(p-vcpus);
+p-distances = xcalloc(b_info-num_vnuma_nodes,
+ sizeof(*p-distances));
+p-num_distances = b_info-num_vnuma_nodes;
+}
+
+for (i = 0; i num_vnuma; i++) {
+XLU_ConfigValue *vnode_spec, *conf_option;
+XLU_ConfigList *vnode_config_list;
+int conf_count;
+libxl_vnode_info *p = b_info-vnuma_nodes[i];
+
+vnode_spec = xlu_cfg_get_listitem2(vnuma, i);
+assert(vnode_spec);
+
+xlu_cfg_value_get_list(config, vnode_spec, vnode_config_list, 0);
+if (!vnode_config_list) {
+fprintf(stderr, xl: cannot get vnode config option list\n);
+exit(1);
+}
+
+for (conf_count = 0;
+ (conf_option =
+ xlu_cfg_get_listitem2(vnode_config_list, conf_count));
+ conf_count++) {
+
+if (xlu_cfg_value_type(conf_option) == XLU_STRING) {
+char *buf, *option_untrimmed, *value_untrimmed;
+char *option, *value;
+char *endptr;
+unsigned long val;
+
+xlu_cfg_value_get_string(config, conf_option, buf, 0);
+
+if (!buf) continue;
+
[Xen-devel] [PATCH v6 07/23] libxl: introduce vNUMA types
A domain can contain several virtual NUMA nodes, hence we introduce an
array in libxl_domain_build_info.
libxl_vnode_info contains the size of memory in that node, the distance
from that node to every nodes, the underlying pnode and a bitmap of
vcpus.
Signed-off-by: Wei Liu wei.l...@citrix.com
Reviewed-by: Dario Faggioli dario.faggi...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Dario Faggioli dario.faggi...@citrix.com
Cc: Elena Ufimtseva ufimts...@gmail.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
Changes in v4:
1. Use MemKB.
Changes in v3:
1. Add commit message.
---
tools/libxl/libxl_types.idl | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 02be466..14c7e7c 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -356,6 +356,13 @@ libxl_domain_sched_params = Struct(domain_sched_params,[
(budget, integer, {'init_val':
'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),
])
+libxl_vnode_info = Struct(vnode_info, [
+(memkb, MemKB),
+(distances, Array(uint32, num_distances)), # distances from this node
to other nodes
+(pnode, uint32), # physical node of this node
+(vcpus, libxl_bitmap), # vcpus in this node
+])
+
libxl_domain_build_info = Struct(domain_build_info,[
(max_vcpus, integer),
(avail_vcpus, libxl_bitmap),
@@ -376,6 +383,8 @@ libxl_domain_build_info = Struct(domain_build_info,[
(disable_migrate, libxl_defbool),
(cpuid, libxl_cpuid_policy_list),
(blkdev_start,string),
+
+(vnuma_nodes, Array(libxl_vnode_info, num_vnuma_nodes)),
(device_model_version, libxl_device_model_version),
(device_model_stubdomain, libxl_defbool),
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 20/23] libxlu: record line and column number when parsing values
Originally only setting has line number recorded. Since we're moving to
more sophisticated API, record line number and column number for
individual value. They are useful for error reporting.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxl/libxlu_cfg.c | 10 --
tools/libxl/libxlu_cfg_i.h| 5 +++--
tools/libxl/libxlu_cfg_y.c| 32 ++--
tools/libxl/libxlu_cfg_y.y| 10 +++---
tools/libxl/libxlu_internal.h | 1 +
5 files changed, 37 insertions(+), 21 deletions(-)
diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index 611f5ec..b921a13 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -311,7 +311,8 @@ const char *xlu_cfg_get_listitem(const XLU_ConfigList
*list, int entry) {
}
-XLU_ConfigValue *xlu__cfg_string_mk(CfgParseContext *ctx, char *atom)
+XLU_ConfigValue *xlu__cfg_string_mk(CfgParseContext *ctx, char *atom,
+int line, int column)
{
XLU_ConfigValue *value = NULL;
@@ -321,6 +322,8 @@ XLU_ConfigValue *xlu__cfg_string_mk(CfgParseContext *ctx,
char *atom)
if (!value) goto xe;
value-type = XLU_STRING;
value-u.string = atom;
+value-line = line;
+value-column = column;
return value;
@@ -333,7 +336,8 @@ XLU_ConfigValue *xlu__cfg_string_mk(CfgParseContext *ctx,
char *atom)
}
XLU_ConfigValue *xlu__cfg_list_mk(CfgParseContext *ctx,
- XLU_ConfigValue *val)
+ XLU_ConfigValue *val,
+ int line, int column)
{
XLU_ConfigValue *value = NULL;
XLU_ConfigValue **values = NULL;
@@ -350,6 +354,8 @@ XLU_ConfigValue *xlu__cfg_list_mk(CfgParseContext *ctx,
value-u.list.nvalues = 1;
value-u.list.avalues = 1;
value-u.list.values = values;
+value-line = line;
+value-column = column;
return value;
diff --git a/tools/libxl/libxlu_cfg_i.h b/tools/libxl/libxlu_cfg_i.h
index 11dc33f..fa46460 100644
--- a/tools/libxl/libxlu_cfg_i.h
+++ b/tools/libxl/libxlu_cfg_i.h
@@ -26,9 +26,10 @@ void xlu__cfg_set_free(XLU_ConfigSetting *set);
void xlu__cfg_set_store(CfgParseContext*, char *name,
XLU_ConfigValue *val, int lineno);
XLU_ConfigValue *xlu__cfg_string_mk(CfgParseContext *ctx,
-char *atom);
+char *atom, int line, int column);
XLU_ConfigValue *xlu__cfg_list_mk(CfgParseContext *ctx,
- XLU_ConfigValue *val);
+ XLU_ConfigValue *val,
+ int line, int column);
void xlu__cfg_list_append(CfgParseContext *ctx,
XLU_ConfigValue *list,
XLU_ConfigValue *val);
diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c
index b05e48b..ec4d95d 100644
--- a/tools/libxl/libxlu_cfg_y.c
+++ b/tools/libxl/libxlu_cfg_y.c
@@ -452,8 +452,8 @@ static const yytype_int8 yyrhs[] =
static const yytype_uint8 yyrline[] =
{
0,47,47,48,50,51,53,54,55,57,
- 59,60,62,63,65,66,68,69,70,72,
- 73,75,77
+ 59,60,62,65,67,68,70,71,72,74,
+ 77,79,81
};
#endif
@@ -1515,69 +1515,73 @@ yyreduce:
/* Line 1806 of yacc.c */
#line 62 libxlu_cfg_y.y
-{ (yyval.value)= xlu__cfg_string_mk(ctx,(yyvsp[(1) - (1)].string)); }
+{ (yyval.value)= xlu__cfg_string_mk(ctx,(yyvsp[(1) - (1)].string),
+ (yylsp[(1) -
(1)]).first_line,
+ (yylsp[(1) -
(1)]).first_column); }
break;
case 13:
/* Line 1806 of yacc.c */
-#line 63 libxlu_cfg_y.y
+#line 65 libxlu_cfg_y.y
{ (yyval.value)= (yyvsp[(3) - (4)].value); }
break;
case 14:
/* Line 1806 of yacc.c */
-#line 65 libxlu_cfg_y.y
+#line 67 libxlu_cfg_y.y
{ (yyval.string)= (yyvsp[(1) - (1)].string); }
break;
case 15:
/* Line 1806 of yacc.c */
-#line 66 libxlu_cfg_y.y
+#line 68 libxlu_cfg_y.y
{ (yyval.string)= (yyvsp[(1) - (1)].string); }
break;
case 16:
/* Line 1806 of yacc.c */
-#line 68 libxlu_cfg_y.y
-{ (yyval.value)= xlu__cfg_list_mk(ctx,NULL); }
+#line 70 libxlu_cfg_y.y
+{ (yyval.value)= xlu__cfg_list_mk(ctx,NULL,0,0); }
break;
case 17:
/* Line 1806 of yacc.c */
-#line 69 libxlu_cfg_y.y
+#line 71 libxlu_cfg_y.y
{ (yyval.value)= (yyvsp[(1) - (1)].value); }
break;
case 18:
/* Line 1806 of yacc.c */
-#line 70 libxlu_cfg_y.y
+#line 72 libxlu_cfg_y.y
{ (yyval.value)= (yyvsp[(1) - (3)].value); }
break;
case 19:
/* Line 1806 of yacc.c */
-#line 72 libxlu_cfg_y.y
-{
[Xen-devel] [PATCH v6 15/23] libxl: build, check and pass vNUMA info to Xen for HVM guest
Transform user supplied vNUMA configuration into libxl internal
representations then libxc representations. Check validity along the
line.
Libxc has more involvement in building vmemranges in HVM case compared
to PV case. The building of vmemranges is placed after xc_hvm_build
returns, because it relies on memory hole information provided by
xc_hvm_build.
Signed-off-by: Wei Liu wei.l...@citrix.com
Reviewed-by: Dario Faggioli dario.faggi...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Dario Faggioli dario.faggi...@citrix.com
Cc: Elena Ufimtseva ufimts...@gmail.com
---
Changes in v6:
1. Fix a minor bug discovered by Dario.
Changes in v5:
1. Check vnode 0 is large enough to accommodate video ram.
Changes in v4:
1. Adapt to new interface.
2. Rename some variables.
3. Use GCREALLOC_ARRAY.
Changes in v3:
1. Rewrite commit log.
---
tools/libxl/libxl_create.c | 9 +++
tools/libxl/libxl_dom.c | 43 ++
tools/libxl/libxl_internal.h | 5
tools/libxl/libxl_vnuma.c| 56
4 files changed, 113 insertions(+)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 98687bd..af04248 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -853,6 +853,15 @@ static void initiate_domain_create(libxl__egc *egc,
goto error_out;
}
+/* Disallow PoD and vNUMA to be enabled at the same time because PoD
+ * pool is not vNUMA-aware yet.
+ */
+if (pod_enabled d_config-b_info.num_vnuma_nodes) {
+ret = ERROR_INVAL;
+LOG(ERROR, Cannot enable PoD and vNUMA at the same time);
+goto error_out;
+}
+
ret = libxl__domain_create_info_setdefault(gc, d_config-c_info);
if (ret) goto error_out;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b58a19b..c1a409d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -893,12 +893,55 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
goto out;
}
+if (info-num_vnuma_nodes != 0) {
+int i;
+
+args.nr_vmemranges = state-num_vmemranges;
+args.vmemranges = libxl__malloc(gc, sizeof(*args.vmemranges) *
+args.nr_vmemranges);
+
+for (i = 0; i args.nr_vmemranges; i++) {
+args.vmemranges[i].start = state-vmemranges[i].start;
+args.vmemranges[i].end = state-vmemranges[i].end;
+args.vmemranges[i].flags = state-vmemranges[i].flags;
+args.vmemranges[i].nid = state-vmemranges[i].nid;
+}
+
+/* Consider video ram belongs to vmemrange 0 -- just shrink it
+ * by the size of video ram.
+ */
+if (((args.vmemranges[0].end - args.vmemranges[0].start) 10)
+ info-video_memkb) {
+LOG(ERROR, vmemrange 0 too small to contain video ram);
+goto out;
+}
+
+args.vmemranges[0].end -= (info-video_memkb 10);
+
+args.nr_vnodes = info-num_vnuma_nodes;
+args.vnode_to_pnode = libxl__malloc(gc, sizeof(*args.vnode_to_pnode) *
+args.nr_vnodes);
+for (i = 0; i args.nr_vnodes; i++)
+args.vnode_to_pnode[i] = info-vnuma_nodes[i].pnode;
+}
+
ret = xc_hvm_build(ctx-xch, domid, args);
if (ret) {
LOGEV(ERROR, ret, hvm building failed);
goto out;
}
+if (info-num_vnuma_nodes != 0) {
+ret = libxl__vnuma_build_vmemrange_hvm(gc, domid, info, state, args);
+if (ret) {
+LOGEV(ERROR, ret, hvm build vmemranges failed);
+goto out;
+}
+ret = libxl__vnuma_config_check(gc, info, state);
+if (ret) goto out;
+ret = set_vnuma_info(gc, domid, info, state);
+if (ret) goto out;
+}
ret = hvm_build_set_params(ctx-xch, domid, info, state-store_port,
state-store_mfn, state-console_port,
state-console_mfn, state-store_domid,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7d1e1cf..e93089a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3408,6 +3408,11 @@ int libxl__vnuma_build_vmemrange_pv(libxl__gc *gc,
uint32_t domid,
libxl_domain_build_info *b_info,
libxl__domain_build_state *state);
+int libxl__vnuma_build_vmemrange_hvm(libxl__gc *gc,
+ uint32_t domid,
+ libxl_domain_build_info *b_info,
+ libxl__domain_build_state *state,
+ struct xc_hvm_build_args *args);
_hidden int libxl__ms_vm_genid_set(libxl__gc *gc, uint32_t domid,
Re: [Xen-devel] Xen's Linux kernel config options
On Thu, Feb 26, 2015 at 11:19:17AM +, Stefano Stabellini wrote:
On Wed, 25 Feb 2015, Luis R. Rodriguez wrote:
On Wed, Feb 25, 2015 at 12:01:31PM +, Stefano Stabellini wrote:
On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Mon, 23 Feb 2015, Luis R. Rodriguez wrote:
On Thu, Feb 19, 2015 at 3:43 PM, Luis R. Rodriguez mcg...@suse.com
wrote:
On Fri, Dec 12, 2014 at 9:29 AM, David Vrabel
david.vra...@citrix.com wrote:
On 12/12/14 13:17, Juergen Gross wrote:
XEN_PVHVM
Move XEN_PVHVM under XEN and have it select PARAVIRT and
PARAVIRT_CLOCK.
FWIW, although it seems we do not want to let users just build
XEN_PVHVM hypervisors I have the changes required now to at least
get
this to build so I do know what it takes.
XEN_FRONTENDXEN_PV ||
XEN_PVH
||
XEN_PVHVM
This enables all the basic infrastructure for frontends: event
channels,
grant tables and Xenbus.
Don't make XEN_FRONTEND depend on any XEN_* variant. It should be
possible to have frontend drivers without support for any of the
PV/PVHVM/PVH guest types.
David, can you elaborate on the type of Xen guest it would be on
x86
its not PV, PVHVM, or PVH? I'm particularly curious about the
xen_domain_type and how it would end up to selected. As it is we
tie
in XEN_PVHVM at build time with XEN_PVH, in order to have XEN_PVHVM
completely removed from XEN_PVH we need quite a bit of code changes
which at least as code exercise I have completed already. If we
want
at the very least xen_domain_type set when XEN_PV, XEN_PVHVM, and
XEN_PVH are not available we need a bit more work.
OK I think I see the issue. We have nothing quite like
xen_guest_init() on x86 enlighten.c, we do have this for ARM and I
think I can that close the gap I'm observing.
Frontends only need event channels, grant
table and xenbus.
Well xenbus_probe_initcall() will check for xen_domain() and that
won't be set on x86 right now unless we have XEN_PV, XEN_PVHVM or
XEN_PVH set -- to start off with. Then
drivers/xen/xenbus/xenbus_client.c will check xen_feature in quite
a
bit of places as well, that won't be set unless
xen_setup_features()
is called which right now is only done on x86
arch/x86/xen/enlighten.c
which as Juergen pointed out, is not needed if you don't have
XEN_PV
or XEN_PVH. As it turns out this is incorrect though, its needed
for
XEN_PVHVM as well and my split exercise in code addresses this.
Now,
at least in my code if you don't have XEN_PV, XEN_PVHVM, or
XEN_PVH we
don't call xen_setup_features() and its unclear to me where or how
that should happen in other cases.
Yeah I think having an x86 equivalent of xen_guest_init() would solve
this, Stefano, thoughts?
Having xen_guest_init() on x86 would be nice. Being able to set
xen_domain_type to XEN_HVM_DOMAIN if we are running on Xen, regardless
of XEN_PV/PVH/PVHVM also makes sense from Linux POV.
OK great, thanks for the feedback.
That said, I don't see much value in removing XEN_PVHVM: why are we
even
doing this? What is the improvement we are seeking?
We would not, the above discussed about the possibility of letting
users enable XEN_PVHVM without XEN_PVH, that's all.
OK, that makes sense.
As is the only thing that can enable XEN_PVHVM is if you enable
XEN_PVH.
This is the bit that we need to change but it shouldn't be difficult.
If we want
xen_guest_init() alone though we might need the decoupling though at
least at build time so that if XEN_PV or XEN_PVH is not selected we'd
at least have XEN_PVHVM. Thoughts?
Today pv(h) and pvhvm have very different boot paths already: pv and pvh
initialize via xen_start_kernel while pvhvm via xen_hvm_guest_init.
Ah I see, this helps a lot thanks!
They are already very decoupled. You just need to make sure that
init_hvm_pv_info() is called regardless on any XEN_PV/PVH/PVHVM configs.
I'm a bit confused about this given that as I see it right now
init_hvm_pv_info() is the Xen x86_hyper-init_platform() callback and that
is
only called on init_hypervisor_platform() *iff* x86_hyper-detect() passed
(returned non-zero), but xen detect() returns 0 in the PV case:
static uint32_t __init xen_hvm_platform(void)
{
[Xen-devel] [PATCH v2] RFC: Automatically check xen's public headers for C++ pitfalls.
Add a check, like the existing check for non-ANSI C in the public
headers, that runs the public headers through a C++ compiler to
flag non-C++-friendly constructs.
Unlike the ANSI C check, we accept GCC-isms (gnu++98), and we also
check various tools-only headers.
Explicitly _not_ addressing the use of 'private' in various fields,
since we'd previously decided not to fix that.
Also tidy up the runes for these checks to be a bit more readable.
Reported-by: Razvan Cojocaru rcojoc...@bitdefender.com
Signed-off-by: Tim Deegan t...@xen.org
Cc: Jan Beulich jbeul...@suse.com
---
v2: test more headers;
define __XEN_TOOLS__;
use g++98 rather than ansi;
tidy the makefile for readability;
add a missing include to flask_op.h, which uses evtchn_port_t.
---
.gitignore| 1 +
config/StdGNU.mk | 2 ++
config/SunOS.mk | 1 +
xen/include/Makefile | 28
xen/include/public/platform.h | 39 ++-
xen/include/public/xsm/flask_op.h | 2 ++
6 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/.gitignore b/.gitignore
index 13ee05b..78958ea 100644
--- a/.gitignore
+++ b/.gitignore
@@ -233,6 +233,7 @@ xen/arch/*/efi/compat.c
xen/arch/*/efi/efi.h
xen/arch/*/efi/runtime.c
xen/include/headers.chk
+xen/include/headers++.chk
xen/include/asm
xen/include/asm-*/asm-offsets.h
xen/include/compat/*
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 4efebe3..e10ed39 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -2,9 +2,11 @@ AS = $(CROSS_COMPILE)as
LD = $(CROSS_COMPILE)ld
ifeq ($(clang),y)
CC = $(CROSS_COMPILE)clang
+CXX= $(CROSS_COMPILE)clang++
LD_LTO = $(CROSS_COMPILE)llvm-ld
else
CC = $(CROSS_COMPILE)gcc
+CXX= $(CROSS_COMPILE)g++
LD_LTO = $(CROSS_COMPILE)ld
endif
CPP= $(CC) -E
diff --git a/config/SunOS.mk b/config/SunOS.mk
index 3316280..c2be37d 100644
--- a/config/SunOS.mk
+++ b/config/SunOS.mk
@@ -2,6 +2,7 @@ AS = $(CROSS_COMPILE)gas
LD = $(CROSS_COMPILE)gld
CC = $(CROSS_COMPILE)gcc
CPP= $(CROSS_COMPILE)gcc -E
+CXX= $(CROSS_COMPILE)g++
AR = $(CROSS_COMPILE)gar
RANLIB = $(CROSS_COMPILE)granlib
NM = $(CROSS_COMPILE)gnm
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 94112d1..d48a642 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -87,13 +87,33 @@ compat/xlat.h: $(addprefix compat/.xlat/,$(xlat-y)) Makefile
ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
-all: headers.chk
+all: headers.chk headers++.chk
-headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/%
public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) Makefile
- for i in $(filter %.h,$^); do $(CC) -ansi -include stdint.h -Wall -W
-Werror -S -o /dev/null -x c $$i || exit 1; echo $$i; done $@.new
+PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard
public/*.h public/*/*.h) $(public-y))
+
+PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/%
public/%hvm/save.h, $(PUBLIC_HEADERS))
+
+headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
+ for i in $(filter %.h,$^); do \
+ $(CC) -x c -ansi -Wall -Werror -include stdint.h \
+ -S -o /dev/null $$i || exit 1; \
+ echo $$i; \
+ done $@.new
+ mv $@.new $@
+
+headers++.chk: $(PUBLIC_HEADERS) Makefile
+ if $(CXX) -v /dev/null 21; then \
+ for i in $(filter %.h,$^); do \
+ $(CXX) -x c++ -std=gnu++98 -Wall -Werror \
+ -D__XEN_TOOLS__ -Dprivate=private_is_a_keyword_in_cpp \
+ -include stdint.h -include public/xen.h \
+ -S -o /dev/null $$i || exit 1; \
+ echo $$i; \
+ done ; \
+ fi $@.new
mv $@.new $@
endif
clean::
- rm -rf compat headers.chk
+ rm -rf compat headers.chk headers++.chk
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 3e340b4..dd03447 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -126,6 +126,26 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_platform_quirk_t);
#define XEN_EFI_query_variable_info 9
#define XEN_EFI_query_capsule_capabilities 10
#define XEN_EFI_update_capsule 11
+
+struct xenpf_efi_guid {
+uint32_t data1;
+uint16_t data2;
+uint16_t data3;
+uint8_t data4[8];
+};
+
+struct xenpf_efi_time {
+uint16_t year;
+uint8_t month;
+uint8_t day;
+uint8_t hour;
+uint8_t min;
+uint8_t sec;
+uint32_t ns;
+int16_t tz;
+uint8_t daylight;
+};
+
struct xenpf_efi_runtime_call {
uint32_t function;
/*
@@ -138,17 +158,7 @@ struct xenpf_efi_runtime_call {
union {
#define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x0001
struct {
-struct xenpf_efi_time {
-
[Xen-devel] [PATCH v6 00/23] Virtual NUMA for PV and HVM
Hi all This is version 6 of this series rebased on top of staging. This patch series implements virtual NUMA support for both PV and HVM guest. That is, admin can configure via libxl what virtual NUMA topology the guest sees. This is the stage 1 (basic vNUMA support) and part of stage 2 (vNUMA-ware ballooning, hypervisor side) described in my previous email to xen-devel [0]. This series is broken into several parts: 1. xen patches: vNUMA debug output and vNUMA-aware memory hypercall support. 2. libxc/libxl support for PV vNUMA. 3. libxc/libxl/hypervisor support for HVM vNUMA. 4. xl vNUMA configuration documentation and parser. One significant difference from Elena's work is that this patch series makes use of multiple vmemranges should there be a memory hole, instead of shrinking ram. This matches the behaviour of real hardware. The vNUMA auto placement algorithm is missing at the moment and Dario is working on it. This series can be found at: git://xenbits.xen.org/people/liuw/xen.git wip.vnuma-v5 With this series, the following configuration can be used to enabled virtual NUMA support, and it works for both PV and HVM guests. vnuma = [ [ pnode=0,size=3000,vcpus=0-3,vdistances=10,20 ], [ pnode=0,size=3000,vcpus=4-7,vdistances=20,10 ], ] For example output of guest NUMA information, please look at [1]. In terms of libxl / libxc internal, things are broken into several parts: 1. libxl interface Users of libxl can only specify how many vnodes a guest can have, but currently they have no control over the actual memory layout. Note that it's fairly easy to export the interface to control memory layout in the future. 2. libxl internal It generates some internal vNUMA configurations when building domain, then transform them into libxc representations. It also validates vNUMA configuration along the line. 3. libxc internal Libxc does what it's told to do. It doesn't do anything smart (in fact, I delibrately didn't put any smart logic inside it). Libxc will also report back some information in HVM case to libxl but that's it. Wei. [0] 2014173606.gc21...@zion.uk.xensource.com [1] 1416582421-10789-1-git-send-email-wei.l...@citrix.com Wei Liu (23): xen: factor out construct_memop_from_reservation xen: move NUMA_NO_NODE to public memory.h as XEN_NUMA_NO_NODE xen: make two memory hypercalls vNUMA-aware libxc: duplicate snippet to allocate p2m_host array libxc: add p2m_size to xc_dom_image libxc: allocate memory with vNUMA information for PV guest libxl: introduce vNUMA types libxl: add vmemrange to libxl__domain_build_state libxl: introduce libxl__vnuma_config_check libxl: x86: factor out e820_host_sanitize libxl: functions to build vmemranges for PV guest libxl: build, check and pass vNUMA info to Xen for PV guest libxc: indentation change to xc_hvm_build_x86.c libxc: allocate memory with vNUMA information for HVM guest libxl: build, check and pass vNUMA info to Xen for HVM guest libxl: disallow memory relocation when vNUMA is enabled libxl: define LIBXL_HAVE_VNUMA libxlu: rework internal representation of setting libxlu: nested list support libxlu: record line and column number when parsing values libxlu: introduce new APIs xl: introduce xcalloc xl: vNUMA support docs/man/xl.cfg.pod.5| 54 +++ tools/libxc/include/xc_dom.h | 13 +- tools/libxc/include/xenguest.h | 11 ++ tools/libxc/xc_dom_arm.c | 1 + tools/libxc/xc_dom_core.c| 8 +- tools/libxc/xc_dom_x86.c | 129 +--- tools/libxc/xc_hvm_build_x86.c | 237 +++-- tools/libxl/Makefile | 2 +- tools/libxl/libxl.h | 7 + tools/libxl/libxl_arch.h | 6 + tools/libxl/libxl_arm.c | 8 + tools/libxl/libxl_create.c | 9 ++ tools/libxl/libxl_dm.c | 6 +- tools/libxl/libxl_dom.c | 120 +++ tools/libxl/libxl_internal.h | 24 +++ tools/libxl/libxl_types.idl | 10 ++ tools/libxl/libxl_vnuma.c| 253 +++ tools/libxl/libxl_x86.c | 105 +++-- tools/libxl/libxlu_cfg.c | 209 ++--- tools/libxl/libxlu_cfg_i.h | 14 +- tools/libxl/libxlu_cfg_y.c | 72 - tools/libxl/libxlu_cfg_y.h | 2 +- tools/libxl/libxlu_cfg_y.y | 18 ++- tools/libxl/libxlu_internal.h| 24 ++- tools/libxl/libxlutil.h | 13 ++ tools/libxl/xl_cmdimpl.c | 150 +- xen/arch/x86/hpet.c | 2 +- xen/arch/x86/irq.c | 4 +- xen/arch/x86/numa.c | 14 +- xen/arch/x86/physdev.c | 2 +- xen/arch/x86/setup.c
[Xen-devel] [PATCH v6 10/23] libxl: x86: factor out e820_host_sanitize
This function gets the machine E820 map and sanitize it according to PV
guest configuration.
This will be used in later patch. No functional change introduced in
this patch.
Signed-off-by: Wei Liu wei.l...@citrix.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
Reviewed-by: Dario Faggioli dario.faggi...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Elena Ufimtseva ufimts...@gmail.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
Changes in v4:
1. Use actual size of the map instead of using E820MAX.
---
tools/libxl/libxl_x86.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 9ceb373..d012b4d 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -207,6 +207,27 @@ static int e820_sanitize(libxl_ctx *ctx, struct e820entry
src[],
return 0;
}
+static int e820_host_sanitize(libxl__gc *gc,
+ libxl_domain_build_info *b_info,
+ struct e820entry map[],
+ uint32_t *nr)
+{
+int rc;
+
+rc = xc_get_machine_memory_map(CTX-xch, map, *nr);
+if (rc 0) {
+errno = rc;
+return ERROR_FAIL;
+}
+
+*nr = rc;
+
+rc = e820_sanitize(CTX, map, nr, b_info-target_memkb,
+ (b_info-max_memkb - b_info-target_memkb) +
+ b_info-u.pv.slack_memkb);
+return rc;
+}
+
static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid,
libxl_domain_config *d_config)
{
@@ -223,15 +244,8 @@ static int libxl__e820_alloc(libxl__gc *gc, uint32_t domid,
if (!libxl_defbool_val(b_info-u.pv.e820_host))
return ERROR_INVAL;
-rc = xc_get_machine_memory_map(ctx-xch, map, E820MAX);
-if (rc 0) {
-errno = rc;
-return ERROR_FAIL;
-}
-nr = rc;
-rc = e820_sanitize(ctx, map, nr, b_info-target_memkb,
- (b_info-max_memkb - b_info-target_memkb) +
- b_info-u.pv.slack_memkb);
+nr = E820MAX;
+rc = e820_host_sanitize(gc, b_info, map, nr);
if (rc)
return ERROR_FAIL;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT
On 25.02.15 at 21:20, dsl...@verizon.com wrote:
On 02/24/15 10:34, Jan Beulich wrote:
On 17.02.15 at 00:05, dsl...@verizon.com wrote:
@@ -501,22 +542,50 @@ static void hvm_free_ioreq_gmfn(struct domain *d,
unsigned long gmfn)
clear_bit(i, d-arch.hvm_domain.ioreq_gmfn.mask);
}
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool_t buf)
+static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, int buf)
{
-struct hvm_ioreq_page *iorp = buf ? s-bufioreq : s-ioreq;
+struct hvm_ioreq_page *iorp = NULL;
+
+switch ( buf )
+{
+case 0:
+iorp = s-ioreq;
+break;
+case 1:
+iorp = s-bufioreq;
+break;
+case 2:
+iorp = s-vmport_ioreq;
+break;
+}
These literals should become an enum.
Paul Durrant asked for #defined values. So it is not clear which way to
go. Will wait for response.
Obviously either would be fine. An enum has the potential advantage
of the compiler being able to check switch statements for completeness
(albeit there are cases where this ends up being a disadvantage).
@@ -2429,9 +2552,6 @@ struct hvm_ioreq_server
*hvm_select_ioreq_server(struct
domain *d,
if ( list_empty(d-arch.hvm_domain.ioreq_server.list) )
return NULL;
-if ( p-type != IOREQ_TYPE_COPY p-type != IOREQ_TYPE_PIO )
-return d-arch.hvm_domain.default_ioreq_server;
Shouldn't this rather be amended than deleted?
The reason is below:
@@ -2474,7 +2594,12 @@ struct hvm_ioreq_server
*hvm_select_ioreq_server(struct domain *d,
BUILD_BUG_ON(IOREQ_TYPE_PIO != HVMOP_IO_RANGE_PORT);
BUILD_BUG_ON(IOREQ_TYPE_COPY != HVMOP_IO_RANGE_MEMORY);
BUILD_BUG_ON(IOREQ_TYPE_PCI_CONFIG != HVMOP_IO_RANGE_PCI);
+BUILD_BUG_ON(IOREQ_TYPE_VMWARE_PORT != HVMOP_IO_RANGE_VMWARE_PORT);
+BUILD_BUG_ON(IOREQ_TYPE_TIMEOFFSET != HVMOP_IO_RANGE_TIMEOFFSET);
+BUILD_BUG_ON(IOREQ_TYPE_INVALIDATE != HVMOP_IO_RANGE_INVALIDATE);
r = s-range[type];
+if ( !r )
+continue;
Why, all of the sudden?
This is the replacement for the deleted if above. Continue will lead
to the same return that was remove above (it is at the end). They are
currently the same because all ioreq servers have the same set of
ranges. But if it would help, I can change continue into the return
default.
So further down you talk of the special range 1 (see there for
further remarks in this regard) - how would r be NULL here in the
first place? That said - yes, making this explicitly do what is
intended (perhaps rather using break instead of return) would
seem very desirable. There simply is no point in continuing the
loop.
@@ -2501,6 +2626,13 @@ struct hvm_ioreq_server
*hvm_select_ioreq_server(struct domain *d,
}
break;
+case IOREQ_TYPE_VMWARE_PORT:
+case IOREQ_TYPE_TIMEOFFSET:
+case IOREQ_TYPE_INVALIDATE:
+if ( rangeset_contains_singleton(r, 1) )
+return s;
This literal 1 at least needs explanation (i.e. a comment).
The comment is below (copied here). Will duplicate it here (with any
adjustments needed):
+ * NOTE: The 'special' range of 1 is what is checked for outside
+ * of the three types of I/O.
How about /* The 'special' range of 1 is checked for being enabled */?
Along these lines, yes (fixed for coding style). And then 1 is not
a range of any kind. I suppose writing it as a proper range (e.g.
[1,1]) would already help.
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -112,6 +112,8 @@ struct __packed segment_register {
#define X86EMUL_RETRY 3
/* (cmpxchg accessor): CMPXCHG failed. Maps to X86EMUL_RETRY in caller. */
#define X86EMUL_CMPXCHG_FAILED 3
+ /* Send part of registers also to DM. */
+#define X86EMUL_VMPORT_SEND4
Introducing a new value here seems rather fragile, as various code
paths you don't touch would need auditing that they do the right
thing upon this value being returned. Plus even conceptually this
doesn't belong here - the instruction emulator shouldn't be concerned
with things like VMware emulation.
The only place I know of where rc is not checked by name is in
x86_emulate.c. There are a lot of 0 and != 0 checks. Also in area of
code there are places that return X86EMUL_OKAY when it looks to me that
the return value is checked for 0 and ignored otherwise.
The point aren't the checks against zero, but the ones against the
#define-d values. Code may exist that, after excluding certain
values, assumes that only some specific value can be left. While
we aim at adding ASSERT()s for such cases, I'm nowhere near to
being convinced this is the case everywhere.
So I will agree that the use of these defines is complex. However, I
need a way to pass back X86EMUL_UNHANDLEABLE and send a few registers to
QEMU. Now
[Xen-devel] [PATCH v10 1/4] tools: correct coding style for psr
- space: remove space after '(' or before ')' in 'if' condition;
- indention: align function definition/call arguments;
Signed-off-by: Chao Peng chao.p.p...@linux.intel.com
Acked-by: Wei Liu wei.l...@citrix.com
---
tools/libxc/include/xenctrl.h | 10 +-
tools/libxc/xc_psr.c | 10 +-
tools/libxl/libxl.h | 11 +++
tools/libxl/libxl_psr.c | 11 +++
tools/libxl/xl_cmdimpl.c | 11 ++-
5 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 790db53..09d819f 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2693,14 +2693,14 @@ typedef enum xc_psr_cmt_type xc_psr_cmt_type;
int xc_psr_cmt_attach(xc_interface *xch, uint32_t domid);
int xc_psr_cmt_detach(xc_interface *xch, uint32_t domid);
int xc_psr_cmt_get_domain_rmid(xc_interface *xch, uint32_t domid,
-uint32_t *rmid);
+ uint32_t *rmid);
int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t *total_rmid);
int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
-uint32_t *upscaling_factor);
+ uint32_t *upscaling_factor);
int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
-uint32_t *l3_cache_size);
-int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
-uint32_t cpu, uint32_t psr_cmt_type, uint64_t *monitor_data);
+ uint32_t *l3_cache_size);
+int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid, uint32_t cpu,
+uint32_t psr_cmt_type, uint64_t *monitor_data);
int xc_psr_cmt_enabled(xc_interface *xch);
#endif
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index 872e6dc..cfae172 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -47,7 +47,7 @@ int xc_psr_cmt_detach(xc_interface *xch, uint32_t domid)
}
int xc_psr_cmt_get_domain_rmid(xc_interface *xch, uint32_t domid,
-uint32_t *rmid)
+ uint32_t *rmid)
{
int rc;
DECLARE_DOMCTL;
@@ -88,7 +88,7 @@ int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t
*total_rmid)
}
int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
-uint32_t *upscaling_factor)
+ uint32_t *upscaling_factor)
{
static int val = 0;
int rc;
@@ -113,7 +113,7 @@ int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
}
int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
- uint32_t *l3_cache_size)
+ uint32_t *l3_cache_size)
{
static int val = 0;
int rc;
@@ -138,8 +138,8 @@ int xc_psr_cmt_get_l3_cache_size(xc_interface *xch,
uint32_t cpu,
return rc;
}
-int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
-uint32_t cpu, xc_psr_cmt_type type, uint64_t *monitor_data)
+int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid, uint32_t cpu,
+xc_psr_cmt_type type, uint64_t *monitor_data)
{
xc_resource_op_t op;
xc_resource_entry_t entries[2];
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c219f59..f784df5 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1476,10 +1476,13 @@ int libxl_psr_cmt_detach(libxl_ctx *ctx, uint32_t
domid);
int libxl_psr_cmt_domain_attached(libxl_ctx *ctx, uint32_t domid);
int libxl_psr_cmt_enabled(libxl_ctx *ctx);
int libxl_psr_cmt_get_total_rmid(libxl_ctx *ctx, uint32_t *total_rmid);
-int libxl_psr_cmt_get_l3_cache_size(libxl_ctx *ctx, uint32_t socketid,
-uint32_t *l3_cache_size);
-int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid,
-uint32_t socketid, uint32_t *l3_cache_occupancy);
+int libxl_psr_cmt_get_l3_cache_size(libxl_ctx *ctx,
+uint32_t socketid,
+uint32_t *l3_cache_size);
+int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx,
+ uint32_t domid,
+ uint32_t socketid,
+ uint32_t *l3_cache_occupancy);
#endif
/* misc */
diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index 0437465..ec3b6e9 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -135,8 +135,9 @@ int libxl_psr_cmt_get_total_rmid(libxl_ctx *ctx, uint32_t
*total_rmid)
return rc;
}
-int libxl_psr_cmt_get_l3_cache_size(libxl_ctx *ctx, uint32_t socketid,
- uint32_t *l3_cache_size)
+int libxl_psr_cmt_get_l3_cache_size(libxl_ctx *ctx,
+uint32_t socketid,
+uint32_t *l3_cache_size)
{
GC_INIT(ctx);
@@ -160,8 +161,10 @@ out:
return rc;
}
-int
Re: [Xen-devel] [PATCH v6 3/5] xen/arm: Make gic-v2 code handle hip04-d01 platform
On 26/02/15 14:45, Frediano Ziglio wrote: I would prefer if we avoid to add more compatibles like that in gic.h. I have a patch to drop a part of this mess. I would advise your to use cherry-pick the commit [1] in your branch. [1] http://xenbits.xen.org/gitweb/?p=people/julieng/xen- unstable.git;a=commit;h=7ba87910e557b06c589c3c0fbc6757fa664d029e Regards, -- Julien Grall Please quote the correct part when you answer. Is this patch in staging? Not yet. But we should avoid to introduce more mess in the headers. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/Dom0: account for shadow/HAP allocation
On 25.02.15 at 18:06, andrew.coop...@citrix.com wrote:
On 25/02/15 14:45, Jan Beulich wrote:
+static unsigned long __init dom0_paging_pages(const struct domain *d,
+ unsigned long nr_pages)
+{
+/* Copied from: libxl_get_required_shadow_memory() */
+unsigned long memkb = nr_pages * (PAGE_SIZE / 1024);
+
+memkb = 4 * (256 * d-max_vcpus + 2 * (memkb / 1024));
I have recently raised a bug against Xapi for similar wrong logic when
calculating the size of the shadow pool.
A per-vcpu reservation of shadow allocation is only needed if shadow
paging is actually in use, and even then should match
shadow_min_acceptable_pages() at 128 pages per vcpu.
If HAP is in use, the only allocations from the shadow pool are for the
EPT/NPT tables (1% of nr_pages), IOMMU tables (another 1% of nr_pages if
in use), and the logdirty radix tree (substantially less than than 1% of
nr_pages).
One could argue that structure such as the vmcs/vmcb should have their
allocations accounted against the domain, in which case a small per-vcpu
component would be appropriate.
However as it currently stands, this calculation wastes 4MB of ram per
vcpu in shadow allocation which is not going to be used.
But you realize that the functional change here explicitly only covers
the shadow case - the PVH (i.e. HAP) case is effectively unchanged
(merely correcting the mistake of not accounting for what gets
actually allocated), and I don't intend any functional change for PVH
(other than said bug fix) with this patch. Hence correcting this (i.e.
lowering the accounted for as well as the allocated amount) as well
as adding accounting for VMCS/VMCB (just like we account for
struct vcpu) should be the subject of a separate patch, presumably
by someone actively working on PVH (and then perhaps at once for
libxc). I also think that this calculation would better become a paging
variant specific hook if calculations differ between shadow and HAP.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Can Xen Project Hypervisor work in Xenserver?
On 26/02/15 15:06, D'Mita Levy wrote: Hello, Assuming one builds the Xen hypervisor avaialable from the http://www.xenproject.org/ respository and then uses it to replace the hypervisor in the Citrix Xenserver /boot directory - will this work. Rather, is it possible to build and mondify the xenproject hypervisor and use it to replace the Citrix Xenserver or would one have to get the code for Xenserver and compile that instead? A plain Xenproject hypervisor will not work under XenServer. However, XenServer is open source and available from https://github.com/xenserver/ You will find that the hypervisor and tools in use is not too different from upstream Xen. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen: credit2: add a few performance counters
On 26.02.15 at 14:37, dario.faggi...@citrix.com wrote: @@ -51,6 +51,19 @@ PERFCOUNTER(migrate_running,csched: migrate_running) PERFCOUNTER(migrate_kicked_away,csched: migrate_kicked_away) PERFCOUNTER(vcpu_hot, csched: vcpu_hot) +/* credit2 specific counters */ +PERFCOUNTER(burn_credits_t2c, csched2: burn_credits_t2c) +PERFCOUNTER(upd_max_weight_quick, cshced2: update_max_weight_quick) +PERFCOUNTER(upd_max_weight_full,cshced2: update_max_weight_full) +PERFCOUNTER(migrate_requested, cshced2: migrate_requested) +PERFCOUNTER(migrate_on_runq,cshced2: migrate_on_runq) +PERFCOUNTER(migrate_no_runq,cshced2: migrate_no_runq) Repeated typos. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/5] libxc: Split off xc_netbsd_user.c
From: Ian Jackson ian.jack...@eu.citrix.com
We are going to want to use some but not all of the machinery
previously in xc_netbsd.c Split the evtchn and ancillary code into its
own file. This part is pure code motion.
But we also have to alter the Makefile, and rename some symbols, as
with xc_minios*.c.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxc/Makefile | 2 +-
tools/libxc/xc_netbsd.c | 168 +
tools/libxc/xc_netbsd_user.c | 196 +++
3 files changed, 198 insertions(+), 168 deletions(-)
create mode 100644 tools/libxc/xc_netbsd_user.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 4ace2b6..0f3396c 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -46,7 +46,7 @@ CTRL_SRCS-$(CONFIG_X86) += xc_pagetab.c
CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
-CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
+CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c xc_netbsd_user.c
CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_privcmd.c
GUEST_SRCS-y :=
diff --git a/tools/libxc/xc_netbsd.c b/tools/libxc/xc_netbsd.c
index 8a90ef3..f940607 100644
--- a/tools/libxc/xc_netbsd.c
+++ b/tools/libxc/xc_netbsd.c
@@ -224,172 +224,6 @@ static struct xc_osdep_ops netbsd_privcmd_ops = {
},
};
-#define EVTCHN_DEV_NAME /dev/xenevt
-
-static xc_osdep_handle netbsd_evtchn_open(xc_evtchn *xce)
-{
-int fd = open(EVTCHN_DEV_NAME, O_NONBLOCK|O_RDWR);
-if ( fd == -1 )
-return XC_OSDEP_OPEN_ERROR;
-
-return (xc_osdep_handle)fd;
-}
-
-static int netbsd_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
-{
-int fd = (int)h;
-return close(fd);
-}
-
-static int netbsd_evtchn_fd(xc_evtchn *xce, xc_osdep_handle h)
-{
-return (int)h;
-}
-
-static int netbsd_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h,
evtchn_port_t port)
-{
-int fd = (int)h;
-struct ioctl_evtchn_notify notify;
-
-notify.port = port;
-
-return ioctl(fd, IOCTL_EVTCHN_NOTIFY, notify);
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_bind_unbound_port(xc_evtchn * xce, xc_osdep_handle h, int domid)
-{
-int fd = (int)h;
-struct ioctl_evtchn_bind_unbound_port bind;
-int ret;
-
-bind.remote_domain = domid;
-
-ret = ioctl(fd, IOCTL_EVTCHN_BIND_UNBOUND_PORT, bind);
-if (ret == 0)
- return bind.port;
-else
- return -1;
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_bind_interdomain(xc_evtchn *xce, xc_osdep_handle h, int domid,
- evtchn_port_t remote_port)
-{
-int fd = (int)h;
-struct ioctl_evtchn_bind_interdomain bind;
-int ret;
-
-bind.remote_domain = domid;
-bind.remote_port = remote_port;
-
-ret = ioctl(fd, IOCTL_EVTCHN_BIND_INTERDOMAIN, bind);
-if (ret == 0)
- return bind.port;
-else
- return -1;
-}
-
-static int netbsd_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h,
evtchn_port_t port)
-{
-int fd = (int)h;
-struct ioctl_evtchn_unbind unbind;
-
-unbind.port = port;
-
-return ioctl(fd, IOCTL_EVTCHN_UNBIND, unbind);
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
-{
-int fd = (int)h;
-struct ioctl_evtchn_bind_virq bind;
-int err;
-
-bind.virq = virq;
-
-err = ioctl(fd, IOCTL_EVTCHN_BIND_VIRQ, bind);
-if (err)
- return -1;
-else
- return bind.port;
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
-{
-int fd = (int)h;
-evtchn_port_t port;
-
-if ( read_exact(fd, (char *)port, sizeof(port)) == -1 )
-return -1;
-
-return port;
-}
-
-static int netbsd_evtchn_unmask(xc_evtchn *xce, xc_osdep_handle h,
evtchn_port_t port)
-{
-int fd = (int)h;
-return write_exact(fd, (char *)port, sizeof(port));
-}
-
-static struct xc_osdep_ops netbsd_evtchn_ops = {
-.open = netbsd_evtchn_open,
-.close = netbsd_evtchn_close,
-
-.u.evtchn = {
- .fd = netbsd_evtchn_fd,
- .notify = netbsd_evtchn_notify,
- .bind_unbound_port = netbsd_evtchn_bind_unbound_port,
- .bind_interdomain = netbsd_evtchn_bind_interdomain,
- .bind_virq = netbsd_evtchn_bind_virq,
- .unbind = netbsd_evtchn_unbind,
- .pending = netbsd_evtchn_pending,
- .unmask = netbsd_evtchn_unmask,
-},
-};
-
-/* Optionally flush file to disk and discard page cache */
-void discard_file_cache(xc_interface *xch, int fd, int flush)
-{
-off_t cur = 0;
-int saved_errno = errno;
-
-if ( flush (fsync(fd) 0) )
-{
-/*PERROR(Failed to flush file: %s, strerror(errno));*/
-goto out;
-}
-
-/*
- * Calculate last page boundry of amount written so far
- * unless we are flushing in which case entire cache
- * is discarded.
[Xen-devel] [rumpuserxen test] 35449: regressions - FAIL
flight 35449 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35449/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen 21909666eb2d85c02770d04691795abfd4417392 baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Antti Kantee po...@iki.fi Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net jobs: build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 339 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/1] xen-netback: remove compilation warning
From: pmarzo marzo.pe...@gmail.com
offset and size are of type uint16_t so the %lu gives a warning
A %u specifier, the same used in size makes gcc happy
Not sure if a %x would be more correct
Signed-off-by: Pedro Marzo Perez marzo.pe...@gmail.com
---
drivers/net/xen-netback/netback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index f7a31d2..3888a2b 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1248,7 +1248,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue
*queue,
/* No crossing a page as the payload mustn't fragment. */
if (unlikely((txreq.offset + txreq.size) PAGE_SIZE)) {
netdev_err(queue-vif-dev,
- txreq.offset: %x, size: %u, end: %lu\n,
+ txreq.offset: %x, size: %u, end: %u\n,
txreq.offset, txreq.size,
(txreq.offset~PAGE_MASK) + txreq.size);
xenvif_fatal_tx_err(queue-vif);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
On 26/02/15 14:46, Pranavkumar Sawargaonkar wrote: Hi Hi Pranavkumar, Also if we just show only one vITS (or only one Virtual v2m frame) instead of two vITS then actual hardware interrupt number and virtual interrupt number which guest will see will become different This will hamper direct irq routing to guest. The IRQ injection should not consider a 1:1 mapping between pIRQ and vIRQ. I have a patch which allow virq != pirq: https://patches.linaro.org/43012/ Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 07/30] PCI: Pass PCI domain number combined with root bus number
Now we could pass PCI domain combined with bus number
in u32 argu. Because in arm/arm64, PCI domain number
is assigned by pci_bus_assign_domain_nr(). So we leave
pci_scan_root_bus() and pci_create_root_bus() in arm/arm64
unchanged. A new function pci_host_assign_domain_nr()
will be introduced for arm/arm64 to assign domain number
in later patch.
Signed-off-by: Yijing Wang wangyij...@huawei.com
CC: Richard Henderson r...@twiddle.net
CC: Ivan Kokshaysky i...@jurassic.park.msu.ru
CC: Matt Turner matts...@gmail.com
CC: Tony Luck tony.l...@intel.com
CC: Fenghua Yu fenghua...@intel.com
CC: Michal Simek mon...@monstr.eu
CC: Ralf Baechle r...@linux-mips.org
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@samba.org
CC: Michael Ellerman m...@ellerman.id.au
CC: Sebastian Ott seb...@linux.vnet.ibm.com
CC: Gerald Schaefer gerald.schae...@de.ibm.com
CC: David S. Miller da...@davemloft.net
CC: Chris Metcalf cmetc...@ezchip.com
CC: Thomas Gleixner t...@linutronix.de
CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com
CC: linux-al...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-i...@vger.kernel.org
CC: linux-m...@linux-mips.org
CC: linuxppc-...@lists.ozlabs.org
CC: linux-s...@vger.kernel.org
CC: linux...@vger.kernel.org
CC: sparcli...@vger.kernel.org
CC: xen-de...@lists.xenproject.org
---
arch/alpha/kernel/pci.c |5 +++--
arch/alpha/kernel/sys_nautilus.c |3 ++-
arch/ia64/pci/pci.c |4 ++--
arch/ia64/sn/kernel/io_init.c|5 +++--
arch/microblaze/pci/pci-common.c |5 +++--
arch/mips/pci/pci.c |4 ++--
arch/powerpc/kernel/pci-common.c |5 +++--
arch/s390/pci/pci.c |5 +++--
arch/sh/drivers/pci/pci.c|5 +++--
arch/sparc/kernel/pci.c |5 +++--
arch/tile/kernel/pci.c |4 ++--
arch/tile/kernel/pci_gx.c|5 +++--
arch/x86/pci/acpi.c |6 +++---
arch/x86/pci/common.c|3 ++-
drivers/pci/xen-pcifront.c |5 +++--
15 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 518b767..b053888 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -336,8 +336,9 @@ common_init_pci(void)
pci_add_resource_offset(resources, hose-mem_space,
hose-mem_space-start);
- bus = pci_scan_root_bus(NULL, next_busno, alpha_mv.pci_ops,
- hose, resources);
+ bus = pci_scan_root_bus(NULL,
+ PCI_DOMBUS(hose-index, next_busno),
alpha_mv.pci_ops,
+ hose, resources);
if (bus)
pci_bus_add_devices(bus);
hose-bus = bus;
diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
index 2c864bb..f7bfdf3 100644
--- a/arch/alpha/kernel/sys_nautilus.c
+++ b/arch/alpha/kernel/sys_nautilus.c
@@ -206,7 +206,8 @@ nautilus_init_pci(void)
unsigned long memtop = max_low_pfn PAGE_SHIFT;
/* Scan our single hose. */
- bus = pci_scan_bus_legacy(0, alpha_mv.pci_ops, hose);
+ bus = pci_scan_bus_legacy(PCI_DOMBUS(hose-index, 0),
+ alpha_mv.pci_ops, hose);
hose-bus = bus;
pcibios_claim_one_bus(bus);
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 48cc657..e4cda61 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -465,8 +465,8 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root
*root)
* should handle the case here, but it appears that IA64 hasn't
* such quirk. So we just ignore the case now.
*/
- pbus = pci_create_root_bus(NULL, bus, pci_root_ops, controller,
- info-resources);
+ pbus = pci_create_root_bus(NULL, PCI_DOMBUS(domain, bus),
+ pci_root_ops, controller, info-resources);
if (!pbus) {
pci_free_resource_list(info-resources);
__release_pci_root_info(info);
diff --git a/arch/ia64/sn/kernel/io_init.c b/arch/ia64/sn/kernel/io_init.c
index 63b43a6..bcdc5b8 100644
--- a/arch/ia64/sn/kernel/io_init.c
+++ b/arch/ia64/sn/kernel/io_init.c
@@ -266,8 +266,9 @@ sn_pci_controller_fixup(int segment, int busnum, struct
pci_bus *bus)
pci_add_resource_offset(resources, res[1],
prom_bussoft_ptr-bs_legacy_mem);
- bus = pci_scan_root_bus(NULL, busnum, pci_root_ops, controller,
- resources);
+ bus = pci_scan_root_bus(NULL,
+ PCI_DOMBUS(controller-segment, busnum),
+ pci_root_ops, controller, resources);
if (bus == NULL) {
kfree(res);
kfree(controller);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index
[Xen-devel] Can Xen Project Hypervisor work in Xenserver?
Hello, Assuming one builds the Xen hypervisor avaialable from the http://www.xenproject.org/ respository and then uses it to replace the hypervisor in the Citrix Xenserver /boot directory - will this work. Rather, is it possible to build and mondify the xenproject hypervisor and use it to replace the Citrix Xenserver or would one have to get the code for Xenserver and compile that instead? Thanks, D'Mita -- D'Mita Levy Cyber Fellow, Applied Research Center Florida International University ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/5] xen/arm: Duplicate gic-v2.c file to support hip04 platform version
On 26/02/15 14:31, Frediano Ziglio wrote: Hi Frediano, On 26/02/15 12:40, Frediano Ziglio wrote: HiSilison Hip04 platform use a slightly different version. This is just a verbatim copy of the file to workaround git not fully supporting copy operation. This is an old verbatim copy. You miss at least one change in the copied GICv2 driver. Regards, -- Julien Grall I think you are referring to changes in staging, right ? Yes. If you already start to diverge from staging that's not good. We may have some patches reaching upstream before this series. You have to keep up-date every-time you send a new version. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] xen: sched: make counters for vCPU tickling generic
On 26.02.15 at 14:37, dario.faggi...@citrix.com wrote: --- a/xen/common/sched_credit2.c +++ b/xen/common/sched_credit2.c @@ -571,9 +571,11 @@ tickle: (unsigned char *)d); } cpumask_set_cpu(ipid, rqd-tickled); +SCHED_STAT_CRANK(tickle_idlers_some); cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ); no_tickle: +SCHED_STAT_CRANK(tickle_idlers_none); return; } Isn't there a return statement missing ahead of no_tickle: now? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] When to use domain creation flag or HVM param?
Hi, On 26/02/15 11:09, Lars Kurth wrote: Tim, Andrew, Jan, it seems as if we are slowly coming to some conclusion on this thread. If I am mistaken, I am wondering whether it would make sense to have an IRC meeting with all the involved stake-holders and report back to the list. I'm not sure where I should answer... We have a similar problem on ARM where we have arch-specific information (GIC version, number of interrupts) which changes between each domain. On Xen 4.5, we took the approach to create a separate DOMCTL for passing information. It has to be called before any VCPUs is created (DOMCTL_set_max_vcpus) and make the code more complicate to handle because we have to defer some domain initialization. I took another approach for Xen 4.6 based on Jan suggestion [1]. A v3 as been send recently [2] and we had some discussion about what is the best approach. I hope this will help to sort out a good approach for both ARM and x86. Regards, [1] http://lists.xen.org/archives/html/xen-devel/2014-11/msg00522.html [2] http://lists.xen.org/archives/html/xen-devel/2015-01/msg01184.html -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] freemem-slack and large memory environments
On Wednesday, February 25, 2015 02:09:50 PM Stefano Stabellini wrote: Is the upshot that Mike doesn't need to do anything further with his patch (i.e. can drop it)? I think so? Yes, I think so. Maybe he could help out testing the patches I am going to write :-) Sorry for not responding to this yesterday. There is still one aspect of my original patch that is important. As the code currently stands, the target for dom0 is set lower during each iteration of the loop. Unless only one iteration is required, dom0 will end up being set to a much lower target than is actually required. There are two ways to fix this issue: - Set the memory target for dom0 once, before entering the loop - During each iteration of the loop, compare the amount of needed memory to the amount of memory which will be available once dom0 hits the target, and only lower the target if additional memory is needed. My patch earlier in this thread does the former, but I think the second option is also possible. Is there a preference between those approaches (or a better idea)? Thanks, Mike ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] RFC: Make xen's public headers a little friendlier for C++.
On 26.02.15 at 16:22, t...@xen.org wrote: At 14:09 + on 26 Feb (1424956161), Jan Beulich wrote: On 26.02.15 at 14:11, t...@xen.org wrote: +headers++.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile ... I don't think limiting this to a subset of the headers is the right thing here: C++ consumers are (most likely) going to be user space, i.e. tools, and those would want to be able to use those excluded headers. OK. I'll have a look through that list. I presume I'll still want to exclude e.g. the arch/ headers on the grounds that users shouldn't be including them directly (and we won't want cross-arch includes)? Aren't even our tools doing cross-arch includes. I've been trying to remember why they're excluded from the C check, but can't. If I'm extending this to cover more headers than the ANSI-C check does, should I also relax the '-ansi' requirement to, e.g. '-std=gnu++98'? I think that would be reasonable nowadays. Anyone wanting compatibility farther back could contribute a patch... and I don't see how this step is being avoided when there's no C++ compiler there. if g++ isn't on the path, 'g++ -v' fails and we end up with an empty headers++.chk file. The line is so long that I overlooked that if g++ -v at the beginning (having expected some different mechanism, like suppressing the dependency in that case). Sorry for the noise. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
Hi On Thu, Feb 26, 2015 at 4:19 PM, Vijay Kilari vijay.kil...@gmail.com wrote: On Wed, Feb 25, 2015 at 3:50 PM, Ian Campbell ian.campb...@citrix.com wrote: On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote: On 24/02/15 7:13 pm, Julien Grall wrote: On 24/02/15 00:23, Manish Jaggi wrote: Because you have to parse all the device tree to remove the reference to the second ITS. It's pointless and can be difficult to do it. Could you please describe the case where it is difficult You have to parse every node in the device tree and replace the msi-parent properties with only one ITS. Thats the idea. If you are able to emulate on ITS, you can do it for multiple one. keeping it simple and similar across dom0/domUs Consider a case where a domU is assigned two PCI devices which are attached to different nodes. (Node is an entity having its own cores are host controllers). The DOM0 view and guest view of the hardware are different. In the case of DOM0, we want to expose the same hardware layout as the host. So if there is 2 ITS then we should expose the 2 ITS. AFAIK Xen has a microkernel design and timer/mmu/smmu/gic/its are handled by xen and a virtualized interface is provided to the guest. So if none of SMMU in the layout of host is presented to dom0 the same can be valid for multiple ITS. SMMU is one of the things which Xen hides from dom0, for obvious reasons. Interrupts are exposed to dom0 in a 1:1 manner. AFAICT there is no reason for ITS to differ here. Since dom0 needs to be able to cope with being able to see all of the host host I/O devices (in the default no-passthrough case), it is possible, if not likely, that it will need the same amount of ITS resources (i.e. numbers of LPIs) as the host provides. In the case of the Guest, we (Xen) controls the memory layout. For Dom0 as well. Not true. For dom0 the memory layout is determined by the host memory layout. The MMIO regions are mapped through 1:1 and the RAM is a subset of the RAM regions of the host physical address space (often in 1:1, but with sufficient h/w support this need not be the case). Therefore we can expose only one ITS. If we follow 2 ITS in dom0 and 1 ITS in domU, how do u expect the Xen GIC ITS emulation driver to work. It should check that request came from a dom0 handle it differently. I think this would be *difficult*. I don't think so. If the vITS is written to handle multiple instances (i.e. in a modular way, as it should be) then it shouldn't matter whether any given domain has 1 or many vITS. The fact that dom0 may have one or more and domU only (currently) has one then becomes largely uninteresting. I have few queries 1) If Dom0 has 'n' ITS nodes, then how does Xen know which virtual ITS command Q is mapped to which Physical ITS command Q. In case of linux, the ITS node is added as msi chip to pci using of_pci_msi_chip_add() and from pci_dev structure we can know which ITS to use. But in case of Xen, when ITS command is trapped we have only dev_id info from ITS command. 2) If DomU is always given one virtual ITS node. If DomU is assinged with two different PCI devices connected to different physical ITS, then Xen vITS driver should know how to map PCI device to physical ITS For the two issues above, Xen should have mapping to pci segment and physical ITS node to use which can be queried by vITS driver and send command on to correct physical ITS Also if we just show only one vITS (or only one Virtual v2m frame) instead of two vITS then actual hardware interrupt number and virtual interrupt number which guest will see will become different This will hamper direct irq routing to guest. - Pranav Vijay ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT
On 26.02.15 at 15:55, dsl...@verizon.com wrote: Well, this is a little confusing (I read this as Paul is fine with 3). Since both Jan Beulich and Keir Fraser want to skip the hole, I will switch to 9. If not leaving a hole makes the code meaningfully simpler, then go with what you have. But if the hole left doesn't cause any other problem for you, then (citing Keir) there's no harm in leaving them unused. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5.99.1 RFC 1/4] xen/arm: Duplicate gic-v2.c file to support hip04 platform version
On Thu, 2015-02-26 at 13:54 +, Julien Grall wrote:
NB: I'm only considering host level stuff here. Our virtualised hardware
as exposed to the guest is well defined right now and any conversation
about deviating from the set of hardware (e.g. providing a guest view to
a non-GIC compliant virtual interrupt controller) would be part of a
separate larger conversation about hvm style guests (and I'd, as you
might imagine, be very reluctant to code to Xen itself to support
non-standard vGICs in particular).
That would mean on platform such as Hisilicon, Guest (including DOM0)
won't be able to use more than 8 CPUs. But I guess this is a fair trade
for having a GIC which differs from the spec.
Correct.
From a what does 'standards compliant' mean PoV we have:
CPUs:
Specified in the ARM ARM (v7=ARM DDI 0406, v8=ARM DDI 0487).
Uncontroversial, I hope!
Host interrupt controllers:
Defined in ARM Generic Interrupt Controller Architecture
Specification (v2=ARM IHI 0048B, v3=???).
AFAICT, for GICv3 there is a hardware spec available (though not
publicly) but no developer spec.
The Architecture Specification is the one we want, I don't know if
that is what you meant by hardware spec, I have one although as you say
I don't think it is public yet.
Referenced from ARMv8 ARM (but not required AFAICT) but
nonetheless this is what we consider when we talk about the
standard interrupt controller.
Host timers:
Defined in the ARMv8 ARM Generic Timers chapter.
Defined as an extension to ARMv7 (don't have doc ref handy). For
our purposes such extensions are considered standardized[*].
It's worth to mention that we don't support generic memory mapped timer
for now. I don't know if we aim to support it.
I don't know either, yet. For now we don't, that's correct.
UARTS:
SBSA defines some (pl011 only?), but there are lots, including
8250-alike ones (ns16550 etc) which is a well established
standard (from x86).
Given that UART drivers are generally small and pretty trivial I
think we can tolerate non-standard (i.e. non-SBSA, non-8250)
ones, so long as they are able to support our vuart interface.
I think the non-{pl011,8250} ones should be subject to non-core
(i.e. community) maintenance as I mentioned previously, i.e
should be listed in MAINTAINERS other than under the core ARM
entry. If we decide to go ahead with this approach I'll ask the
appropriate people to update MAINTAINERS.
At that time we have 3 non-compliant UART in Xen: exynos4210, scif and
omap.
Having maintainers per non-compliant UART would make some generic more
complicate to upstream.
In reality by a negligible amount, I expect.
Indeed, it would require all the ack.
I don't think that's true, an update to core which requires updates to
all drivers shouldn't be blocked by non-responsive maintainer. If they
don't respond then their driver might break.
This all works fine for much larger projects. Take Linux for example:
you don't see them getting stalled on core infrastructure updates
because the author of some niche serial driver isn't responding to his
mail. They do the sensible thing and get on with it.
[..]
I think the above is a workable definition of what it is reasonable to
expect the core Xen/ARM maintainers to look after (with that particular
hat on) vs. what it should be expected for interested members of the
community to step up and maintain (where the people who happen to be
core Xen/ARM maintainers may occasionally chose to have such a hat too.)
I got few questions about it:
- What happen if the maintainers of a specific driver (UART/IRQ
controller) doesn't answer?
Then their driver might break or bitrot, and eventually be removed.
- How do we handle possible security issue related to a specific
driver? Is it even considered as a security one?
In the same way we do today with any security issue, which is to say the
security team will deal with it, bringing in people as they feel
appropriate (and the discoverer agrees). This is no different to a bug
in any other bit of Xen who's maintainer is not on the security team.
- As a new drivers would tight to a new set of maintainers, how do we
decide that a new drivers is accepted in Xen?
In the normal way.
Given the governance spec [1], we may decide to reject a maintainers for
some reason. Does it mean the drivers is rejected too?
If someone writes a driver for a h/w component and wants to be the
maintainer then there is no normal reason to reject them IMHO.
To put it another way, if we don't want to accept them as maintainer for
the driver which they have written then why would we want to accept the
driver itself.
Re: [Xen-devel] [PATCH] RFC: Make xen's public headers a little friendlier for C++.
At 14:09 + on 26 Feb (1424956161), Jan Beulich wrote: On 26.02.15 at 14:11, t...@xen.org wrote: -headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) Makefile +PUBLIC_HEADERS_TO_CHECK := $(filter-out public/arch-% public/%ctl.h public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) + +headers.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile for i in $(filter %.h,$^); do $(CC) -ansi -include stdint.h -Wall -W -Werror -S -o /dev/null -x c $$i || exit 1; echo $$i; done $@.new mv $@.new $@ +headers++.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile ... I don't think limiting this to a subset of the headers is the right thing here: C++ consumers are (most likely) going to be user space, i.e. tools, and those would want to be able to use those excluded headers. OK. I'll have a look through that list. I presume I'll still want to exclude e.g. the arch/ headers on the grounds that users shouldn't be including them directly (and we won't want cross-arch includes)? If I'm extending this to cover more headers than the ANSI-C check does, should I also relax the '-ansi' requirement to, e.g. '-std=gnu++98'? + if g++ -v /dev/null; then for i in $(filter %.h,$^); do g++ -ansi -include stdint.h -Wall -W -Werror -S -o /dev/null -x c++ -Dprivate=private_is_a_keyword_in_c_plus_plus $$i || exit 1; echo $$i; done ; fi $@.new You may want to define __XEN_TOOLS__ (and un-define __XEN__) here. OK. I wonder how many more things will break when I do that. :) Also g++ ought to by abstracted to $(CXX) Sure, I'll define up $(CXX) in StdGnu.mk. and I don't see how this step is being avoided when there's no C++ compiler there. if g++ isn't on the path, 'g++ -v' fails and we end up with an empty headers++.chk file. It doesn't deal with a present-but-broken g++ but that way lies autoconf. --- a/xen/include/public/platform.h +++ b/xen/include/public/platform.h These changes went in a few minutes ago. Good-oh; I'll drop them from a v2. Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT
On 02/26/15 06:49, Paul Durrant wrote:
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 26 February 2015 08:08
To: Don Slutz
Cc: Aravind Gopalakrishnan; Suravee Suthikulpanit; Andrew Cooper; Ian
Campbell; Paul Durrant; George Dunlap; Ian Jackson; Stefano Stabellini; Eddie
Dong; Jun Nakajima; Kevin Tian; xen-devel@lists.xen.org; Boris Ostrovsky;
Konrad Rzeszutek Wilk; Keir (Xen.org); Tim (Xen.org)
Subject: Re: [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT
On 25.02.15 at 21:20, dsl...@verizon.com wrote:
On 02/24/15 10:34, Jan Beulich wrote:
On 17.02.15 at 00:05, dsl...@verizon.com wrote:
@@ -501,22 +542,50 @@ static void hvm_free_ioreq_gmfn(struct
domain *d, unsigned long gmfn)
clear_bit(i, d-arch.hvm_domain.ioreq_gmfn.mask);
}
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s,
bool_t buf)
+static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, int
buf)
{
-struct hvm_ioreq_page *iorp = buf ? s-bufioreq : s-ioreq;
+struct hvm_ioreq_page *iorp = NULL;
+
+switch ( buf )
+{
+case 0:
+iorp = s-ioreq;
+break;
+case 1:
+iorp = s-bufioreq;
+break;
+case 2:
+iorp = s-vmport_ioreq;
+break;
+}
These literals should become an enum.
Paul Durrant asked for #defined values. So it is not clear which way to
go. Will wait for response.
Obviously either would be fine. An enum has the potential advantage
of the compiler being able to check switch statements for completeness
(albeit there are cases where this ends up being a disadvantage).
I'm fine with an enum... just not with (repeated) magic numbers in the code.
Ok, will use enum.
[snip]
Some background. When Julien Grall added 2, this was said:
Keir Fraser
[...]
They were almost certainly used for representing R-M-W ALU operations
back
in the days of the old IO emulator, very long ago. Still, there''s no
harm in
leaving them unused.
[...]
I did find the old defn:
dcs-xen-54:~/xengit show 4ff8936 | grep IOREQ_TYPE_
#define IOREQ_TYPE_PIO 0 /* pio */
#define IOREQ_TYPE_COPY 1 /* mmio ops */
#define IOREQ_TYPE_AND 2
#define IOREQ_TYPE_OR 3
#define IOREQ_TYPE_XOR 4
#define IOREQ_TYPE_XCHG 5
#define IOREQ_TYPE_ADD 6
[...]
Which matches what Keir Fraser said.
I did not find why Paul Durrant did not use 9. I can only find it as 2
in all Paul's patch sets. Which is closely connected to:
BUILD_BUG_ON(IOREQ_TYPE_PIO != HVMOP_IO_RANGE_PORT);
BUILD_BUG_ON(IOREQ_TYPE_COPY !=
HVMOP_IO_RANGE_MEMORY);
BUILD_BUG_ON(IOREQ_TYPE_PCI_CONFIG !=
HVMOP_IO_RANGE_PCI);
(a new hyper call arg). This also did not add a hole in range so
Paul Durrant did not have to check for a range hole.
So I did just like Paul Durrant did. He also approved the patch with
this number in QEMU. Since this is now in upstream QEMU, changing it at
this time is a slower process. Since the only time QEMU uses its
version is when Xen header files are missing, I do not see how a QEMU
built with its version would be usable as a QEMU for Xen. So I am
happy to change to a new number like 9.
Yes please. I'm not saying we absolutely have to correct the one
Paul added (unless we learn it causes problems), but I think we
should avoid making the same (even if only potential) mistake twice.
Of course it would help to get insight from Paul (now Cc-ed) here.
I used the hole because I really did not think anyone would
ever expect to use an ancient emulator against a recent
Xen. Given there has been no fallout I don't see why we can't
use the hole.
Well, this is a little confusing (I read this as Paul is fine with 3).
Since both Jan Beulich and Keir Fraser want to skip the hole, I will
switch to 9.
-Don Slutz
Paul
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] xen: sched: make counters for vCPU tickling generic
On Thu, 2015-02-26 at 15:22 +, Jan Beulich wrote: On 26.02.15 at 14:37, dario.faggi...@citrix.com wrote: --- a/xen/common/sched_credit2.c +++ b/xen/common/sched_credit2.c @@ -571,9 +571,11 @@ tickle: (unsigned char *)d); } cpumask_set_cpu(ipid, rqd-tickled); +SCHED_STAT_CRANK(tickle_idlers_some); cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ); no_tickle: +SCHED_STAT_CRANK(tickle_idlers_none); return; } Isn't there a return statement missing ahead of no_tickle: now? There is. I reworked this last minute, and overlooked this... sorry. Will fix for v2. Thanks and Regards, Dario signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/5] xen/arm: Duplicate gic-v2.c file to support hip04 platform version
On 26/02/15 14:31, Frediano Ziglio wrote: Hi Frediano, On 26/02/15 12:40, Frediano Ziglio wrote: HiSilison Hip04 platform use a slightly different version. This is just a verbatim copy of the file to workaround git not fully supporting copy operation. This is an old verbatim copy. You miss at least one change in the copied GICv2 driver. Regards, -- Julien Grall I think you are referring to changes in staging, right ? Yes. If you already start to diverge from staging that's not good. We may have some patches reaching upstream before this series. You have to keep up-date every-time you send a new version. Regards, Ok, I always used master as a start, not staging. I'll rebase on staging then. Frediano ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/4] xen: sched: rework and add performance counters
On 26.02.15 at 14:36, dario.faggi...@citrix.com wrote: A small series that refactors a few of the existing scheduling related performance counters, making them generic and updating them from all schedulers, rather than just in Credit1. It also (in the last patch) add a few new counters, specific to Credit2. Thanks and Regards, Dario --- Dario Faggioli (4): xen: sched: honour generic perf conuters in the RTDS scheduler xen: sched: make counters for vCPU sleep and wakeup generic xen: sched: make counters for vCPU tickling generic xen: credit2: add a few performance counters xen/common/sched_credit2.c | 37 + xen/common/sched_rt.c| 18 ++ xen/include/xen/perfc_defn.h | 29 + With the typos in patch 4 fixed, all changes to this file in this series Acked-by: Jan Beulich jbeul...@suse.com Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 35360: regressions - FAIL
flight 35360 libvirt real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35360/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 13 guest-destroy fail REGR. vs. 34580 test-amd64-amd64-libvirt 13 guest-destroy fail REGR. vs. 34580 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass version targeted for testing: libvirt efd30e2e1cb2b9e467c225db92e8a16eb8de2632 baseline version: libvirt 4438646c0d7ff5c4857e6b010032f0fdf0a6039c People who touched revisions under test: Cole Robinson crobi...@redhat.com Daniel Hansel daniel.han...@linux.vnet.ibm.com Daniel P. Berrange berra...@redhat.com Jiri Denemark jdene...@redhat.com Ján Tomko jto...@redhat.com Laine Stump la...@laine.org Luyao Huang lhu...@redhat.com Marek Marczykowski marma...@invisiblethingslab.com Marek Marczykowski-Górecki marma...@invisiblethingslab.com Martin Kletzander mklet...@redhat.com Michal Privoznik mpriv...@redhat.com Mikhail Feoktistov mfeoktis...@parallels.com Pavel Hrdina phrd...@redhat.com Peter Krempa pkre...@redhat.com Prerna Saxena pre...@linux.vnet.ibm.com Stefan Zimmermann s...@linux.vnet.ibm.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 849 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 03/30] xen/PCI: Don't use deprecated function pci_scan_bus_parented()
From: Arnd Bergmann a...@arndb.de
Use pci_scan_root_bus() instead of deprecated function
pci_scan_bus_parented().
Signed-off-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Yijing Wang wangyij...@huawei.com
CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com
CC: xen-de...@lists.xenproject.org
---
drivers/pci/xen-pcifront.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index b1ffebe..240ddbc 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -446,6 +446,7 @@ static int pcifront_scan_root(struct pcifront_device *pdev,
unsigned int domain, unsigned int bus)
{
struct pci_bus *b;
+ LIST_HEAD(resources);
struct pcifront_sd *sd = NULL;
struct pci_bus_entry *bus_entry = NULL;
int err = 0;
@@ -470,17 +471,20 @@ static int pcifront_scan_root(struct pcifront_device
*pdev,
err = -ENOMEM;
goto err_out;
}
+ pci_add_resource(resources, ioport_resource);
+ pci_add_resource(resources, iomem_resource);
pcifront_init_sd(sd, domain, bus, pdev);
pci_lock_rescan_remove();
- b = pci_scan_bus_parented(pdev-xdev-dev, bus,
- pcifront_bus_ops, sd);
+ b = pci_scan_root_bus(pdev-xdev-dev, bus,
+ pcifront_bus_ops, sd, resources);
if (!b) {
dev_err(pdev-xdev-dev,
Error creating PCI Frontend Bus!\n);
err = -ENOMEM;
pci_unlock_rescan_remove();
+ pci_free_resource_list(resources);
goto err_out;
}
@@ -488,7 +492,7 @@ static int pcifront_scan_root(struct pcifront_device *pdev,
list_add(bus_entry-list, pdev-root_buses);
- /* pci_scan_bus_parented skips devices which do not have a have
+ /* pci_scan_root_bus skips devices which do not have a have
* devfn==0. The pcifront_scan_bus enumerates all devfn. */
err = pcifront_scan_bus(pdev, domain, bus, b);
--
1.7.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 3/5] xen/arm: Make gic-v2 code handle hip04-d01 platform
Hi Frediano,
On 26/02/15 12:40, Frediano Ziglio wrote:
diff --git a/xen/arch/arm/domain_build.c
b/xen/arch/arm/domain_build.c
index c2dcb49..0834053 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1038,6 +1038,7 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
static const struct dt_device_match gic_matches[] __initconst =
{
DT_MATCH_GIC_V2,
+DT_MATCH_GIC_HIP04,
DT_MATCH_GIC_V3,
{ /* sentinel */ },
};
I think this is the perfect time to introduce a callback to check if
the node is a GIC.
This would avoid to grow up this structure.
[..]
Actually looking at assignment of dt_interrupt_controller (a dt_device_node)
and calls to register_gic_ops there is a one-to-one correspondence so you can
check if node == dt_interrupt_controller in handle_node instead of using a
manually compiled gic_matches and checking with dt_match_node? This way I could
even avoid to defined in a header the DT compatible string.
-static const char * const gicv2_dt_compat[] __initconst =
+static const char * const hip04gic_dt_compat[] __initconst =
{
-DT_COMPAT_GIC_CORTEX_A15,
-DT_COMPAT_GIC_CORTEX_A7,
-DT_COMPAT_GIC_400,
+DT_COMPAT_GIC_HIP04,
NULL
};
-DT_DEVICE_START(gicv2, GICv2:, DEVICE_GIC)
-.compatible = gicv2_dt_compat,
-.init = gicv2_init,
+DT_DEVICE_START(hip04gic, GIC-HIP04:, DEVICE_GIC)
The : was a mistake in the GICv2. Please don't reproduce it here.
+.compatible = hip04gic_dt_compat,
+.init = hip04gic_init,
DT_DEVICE_END
/*
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index
390c8b0..e4512a8 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -565,12 +565,13 @@ static void do_sgi(struct cpu_user_regs *regs,
enum gic_sgi sgi) void gic_interrupt(struct cpu_user_regs *regs, int
is_fiq) {
unsigned int irq;
+unsigned int max_irq = gic_hw_ops-info-nr_lines;
do {
/* Reading IRQ will ACK it */
irq = gic_hw_ops-read_irq();
-if ( likely(irq = 16 irq 1021) )
+if ( likely(irq = 16 irq max_irq) )
{
local_irq_enable();
do_IRQ(regs, irq, is_fiq);
This change should belong to a separate patch.
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..a36f486 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -160,6 +160,10 @@
DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7),
\
DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
+#define DT_COMPAT_GIC_HIP04 hisilicon,hip04-intc
+
+#define DT_MATCH_GIC_HIP04 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
+
#define DT_COMPAT_GIC_V3 arm,gic-v3
#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_V3)
I would prefer if we avoid to add more compatibles like that in gic.h.
I have a patch to drop a part of this mess. I would advise your to use
cherry-pick the commit [1] in your branch.
[1]
http://xenbits.xen.org/gitweb/?p=people/julieng/xen-
unstable.git;a=commit;h=7ba87910e557b06c589c3c0fbc6757fa664d029e
Regards,
--
Julien Grall
Is this patch in staging?
Frediano
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/5] Build libxc on rump kernels
This is a series done by Ian Jackson. I only changed a few macros and rewrote some commit logs. With this series we can build libxc with rump kernels. Wei. Ian Jackson (5): NetBSDRump: provide evtchn.h libxc: Split off xc_minios_privcmd.c libxc: Split off xc_netbsd_user.c libxc: minios: Introduce abstraction for files[] libxc: rumpxen: Provide xc_osdep_info tools/include/xen-sys/NetBSDRump/evtchn.h | 86 tools/libxc/Makefile | 6 +- tools/libxc/xc_minios.c | 243 +- tools/libxc/xc_minios_privcmd.c | 322 ++ tools/libxc/xc_netbsd.c | 168 +--- tools/libxc/xc_netbsd_rumpkern.c | 62 ++ tools/libxc/xc_netbsd_user.c | 196 ++ tools/libxc/xc_private.h | 3 + 8 files changed, 678 insertions(+), 408 deletions(-) create mode 100644 tools/include/xen-sys/NetBSDRump/evtchn.h create mode 100644 tools/libxc/xc_minios_privcmd.c create mode 100644 tools/libxc/xc_netbsd_rumpkern.c create mode 100644 tools/libxc/xc_netbsd_user.c -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
On Thu, 2015-02-26 at 16:19 +0530, Vijay Kilari wrote: On Wed, Feb 25, 2015 at 3:50 PM, Ian Campbell ian.campb...@citrix.com wrote: On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote: On 24/02/15 7:13 pm, Julien Grall wrote: On 24/02/15 00:23, Manish Jaggi wrote: Because you have to parse all the device tree to remove the reference to the second ITS. It's pointless and can be difficult to do it. Could you please describe the case where it is difficult You have to parse every node in the device tree and replace the msi-parent properties with only one ITS. Thats the idea. If you are able to emulate on ITS, you can do it for multiple one. keeping it simple and similar across dom0/domUs Consider a case where a domU is assigned two PCI devices which are attached to different nodes. (Node is an entity having its own cores are host controllers). The DOM0 view and guest view of the hardware are different. In the case of DOM0, we want to expose the same hardware layout as the host. So if there is 2 ITS then we should expose the 2 ITS. AFAIK Xen has a microkernel design and timer/mmu/smmu/gic/its are handled by xen and a virtualized interface is provided to the guest. So if none of SMMU in the layout of host is presented to dom0 the same can be valid for multiple ITS. SMMU is one of the things which Xen hides from dom0, for obvious reasons. Interrupts are exposed to dom0 in a 1:1 manner. AFAICT there is no reason for ITS to differ here. Since dom0 needs to be able to cope with being able to see all of the host host I/O devices (in the default no-passthrough case), it is possible, if not likely, that it will need the same amount of ITS resources (i.e. numbers of LPIs) as the host provides. In the case of the Guest, we (Xen) controls the memory layout. For Dom0 as well. Not true. For dom0 the memory layout is determined by the host memory layout. The MMIO regions are mapped through 1:1 and the RAM is a subset of the RAM regions of the host physical address space (often in 1:1, but with sufficient h/w support this need not be the case). Therefore we can expose only one ITS. If we follow 2 ITS in dom0 and 1 ITS in domU, how do u expect the Xen GIC ITS emulation driver to work. It should check that request came from a dom0 handle it differently. I think this would be *difficult*. I don't think so. If the vITS is written to handle multiple instances (i.e. in a modular way, as it should be) then it shouldn't matter whether any given domain has 1 or many vITS. The fact that dom0 may have one or more and domU only (currently) has one then becomes largely uninteresting. I have few queries 1) If Dom0 has 'n' ITS nodes, then how does Xen know which virtual ITS command Q is mapped to which Physical ITS command Q. In case of linux, the ITS node is added as msi chip to pci using of_pci_msi_chip_add() and from pci_dev structure we can know which ITS to use. But in case of Xen, when ITS command is trapped we have only dev_id info from ITS command. With the proper PCI infrastructure in place we can map the vdev_id to a pdev_id, and from there to our own struct pci_dev The mapping from pdev_id to pci_dev is based on the PHYSDEVOP_pci_host_bridge_add and PHYSDEVOP_pci_device_add calls I described just now in my mail to Manish in this thread (specifically pci_device_add creates and registers struct pci_dev I think). 2) If DomU is always given one virtual ITS node. If DomU is assinged with two different PCI devices connected to different physical ITS, then Xen vITS driver should know how to map PCI device to physical ITS Correct, I think that all falls out from the proper tracking of the vdev_id to pdev_id and from vits to pits for a given domain and the management/tracking of the struct pci_dev. Ian. For the two issues above, Xen should have mapping to pci segment and physical ITS node to use which can be queried by vITS driver and send command on to correct physical ITS Vijay ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: remove LIBXL_MAXMEM_CONSTANT
On Thu, 2015-02-26 at 12:19 +, Stefano Stabellini wrote: On Wed, 25 Feb 2015, Don Slutz wrote: On 02/25/15 10:07, Stefano Stabellini wrote: LIBXL_MAXMEM_CONSTANT is used to increase the maxmem setting for a domain by a constant amount. As it is not clear the reason why we should be doing this, remove the constant. Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com CC: mlati...@suse.com CC: ian.campb...@citrix.com --- I think that some sort of link to commit 901230f in QEMU: commit 901230fd8ce053cc21312a2eca2f3ba9f1d103f2 Author: Stefano Stabellini stefano.stabell...@eu.citrix.com Date: Wed Dec 3 08:15:19 2014 -0500 xen-hvm: increase maxmem before calling xc_domain_populate_physmap Increase maxmem before calling xc_domain_populate_physmap_exact to avoid the risk of running out of guest memory. This way we can also avoid complex memory calculations in libxl at domain construction time. This patch fixes an abort() when assigning more than 4 NICs to a VM. upstream-commit-id: c1d322e6048796296555dd36fdd102d7fa2f50bf Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Signed-off-by: Don Slutz dsl...@verizon.com Because after this patch and without a correct QEMU, the number of e1000 NICs a guest can use is less then 4. That is true, in fact is not even a single emulated NIC in my tests. I can either ask for a backport of c1d322e6048796296555dd36fdd102d7fa2f50bf xen-hvm: increase maxmem before calling xc_domain_populate_physmap to all QEMU stable branches, It can't hurt to ask, I think? or we just have to keep this around for now and maybe just add a comment on why it is needed. (assuming they say no to the backports) Could we at least make it x86/HVM specific? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: xen config changes v4
On Thu, 26 Feb 2015, David Vrabel wrote: On 26/02/15 04:59, Juergen Gross wrote: So we are again in the situation that pv-drivers always imply the pvops kernel (PARAVIRT selected). I started the whole Kconfig rework to eliminate this dependency. Yes. Can you produce a series that just addresses this one issue. In the absence of any concrete requirement for this big Kconfig reorg I I don't think it is helpful. I clearly missed some context as I didn't realize that this was the intended goal. Why do we want this? Please explain as it won't come for free. We have a few PV interfaces for HVM guests that need PARAVIRT in Linux in order to be used, for example pv_time_ops and HVMOP_pagetable_dying. They are critical performance improvements and from the interface perspective, small enough that doesn't make much sense having a separate KConfig option for them. In order to reach the goal above we necessarily need to introduce a differentiation in terms of PV on HVM guests in Linux: 1) basic guests with PV network, disk, etc but no PV timers, no HVMOP_pagetable_dying, no PV IPIs 2) full PV on HVM guests that have PV network, disk, timers, HVMOP_pagetable_dying, PV IPIs and anything else that makes sense. 2) is much faster than 1) on Xen and 2) is only a tiny bit slower than 1) on native x86 From Xen perspective and from code maintenance perspective I don't think it makes sense to have the separation, actually it would make things slower and harder to maintain. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] backport c1d322e6048796296555dd36fdd102d7fa2f50bf to all stable trees
Hi all, I would like to request a backport of commit c1d322e6048796296555dd36fdd102d7fa2f50bf Author: Stefano Stabellini stefano.stabell...@eu.citrix.com Date: Wed Dec 3 08:15:19 2014 -0500 xen-hvm: increase maxmem before calling xc_domain_populate_physmap to all QEMU stable trees. Which ones are the currently maintained trees? It applies without issues to 2.2, 2.1, 2.0, 1.7, 1.6, 1.5. The filename in the commit needs to be changed from xen-hvm.c to xen-all.c for 1.4, 1.3, 1.2, 1.1. I didn't go father back. Thanks, Stefano ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/5] xen/arm: Duplicate gic-v2.c file to support hip04 platform version
Hi Frediano, On 26/02/15 12:40, Frediano Ziglio wrote: HiSilison Hip04 platform use a slightly different version. This is just a verbatim copy of the file to workaround git not fully supporting copy operation. This is an old verbatim copy. You miss at least one change in the copied GICv2 driver. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
Hi Ian, On 26/02/15 11:12, Ian Campbell wrote: I have few queries 1) If Dom0 has 'n' ITS nodes, then how does Xen know which virtual ITS command Q is mapped to which Physical ITS command Q. In case of linux, the ITS node is added as msi chip to pci using of_pci_msi_chip_add() and from pci_dev structure we can know which ITS to use. But in case of Xen, when ITS command is trapped we have only dev_id info from ITS command. With the proper PCI infrastructure in place we can map the vdev_id to a pdev_id, and from there to our own struct pci_dev The mapping from pdev_id to pci_dev is based on the PHYSDEVOP_pci_host_bridge_add and PHYSDEVOP_pci_device_add calls I described just now in my mail to Manish in this thread (specifically pci_device_add creates and registers struct pci_dev I think). We may need an hypercall to map the dev_id to a vdev_id. IIRC, Vijay and Manish was already planned to add one. 2) If DomU is always given one virtual ITS node. If DomU is assinged with two different PCI devices connected to different physical ITS, then Xen vITS driver should know how to map PCI device to physical ITS Correct, I think that all falls out from the proper tracking of the vdev_id to pdev_id and from vits to pits for a given domain and the management/tracking of the struct pci_dev. I think this is the right way to go. Though I haven't read the ITS spec closely. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 5/5] libxc: rumpxen: Provide xc_osdep_info
From: Ian Jackson ian.jack...@eu.citrix.com
This allows programs which use the bulk of libxc to link. We use
/dev/xenevt for event channels, the raw minios functions for privcmd
and gnttab, and the netbsd versions of discard_file_cache and
xc_memalign.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
[ wei: wrap long lines, adapt to changes in previous patch ]
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxc/Makefile | 2 ++
tools/libxc/xc_minios_privcmd.c | 36 +--
tools/libxc/xc_netbsd_rumpkern.c | 62
3 files changed, 98 insertions(+), 2 deletions(-)
create mode 100644 tools/libxc/xc_netbsd_rumpkern.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 0f3396c..bce2dd2 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -48,6 +48,8 @@ CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c xc_netbsd_user.c
CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_privcmd.c
+CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_netbsd_rumpkern.c xc_netbsd_user.c
+CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_minios_privcmd.c
GUEST_SRCS-y :=
GUEST_SRCS-y += xg_private.c xc_suspend.c
diff --git a/tools/libxc/xc_minios_privcmd.c b/tools/libxc/xc_minios_privcmd.c
index 27d9076..a8b1102 100644
--- a/tools/libxc/xc_minios_privcmd.c
+++ b/tools/libxc/xc_minios_privcmd.c
@@ -41,9 +41,19 @@
#include xc_private.h
-#ifdef __RUMPRUN___
+#ifdef __RUMPRUN__
# define map_frames_ex minios_map_frames_ex
-#endif /* __RUMPRUN__ */
+
+static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
+{
+return 1;
+}
+static int minios_privcmd_close(xc_interface *xch, xc_osdep_handle h)
+{
+return 0;
+}
+
+#else /* !__RUMPRUN__ */
void minios_interface_close_fd(int fd);
void minios_gnttab_close_fd(int fd);
@@ -69,6 +79,8 @@ void minios_interface_close_fd(int fd)
files[fd].type = FTYPE_NONE;
}
+#endif /* !__RUMPRUN__ */
+
static void *minios_privcmd_alloc_hypercall_buffer(xc_interface *xch,
xc_osdep_handle h,
int npages)
@@ -208,6 +220,24 @@ struct xc_osdep_ops xc_privcmd_ops = {
},
};
+#ifdef __RUMPRUN__
+
+static struct gntmap static_gntmap;
+
+#define GNTMAP(h) static_gntmap
+
+static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
+{
+return 1;
+}
+
+static int minios_gnttab_close(xc_gnttab *xcg, xc_osdep_handle h)
+{
+return 0;
+}
+
+#else /* !__RUMPRUN__ */
+
#define GNTMAP(h) (files[(int)(h)].gntmap)
static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
@@ -231,6 +261,8 @@ void minios_gnttab_close_fd(int fd)
files[fd].type = FTYPE_NONE;
}
+#endif /* !__RUMPRUN__ */
+
static void *minios_gnttab_grant_map(xc_gnttab *xcg, xc_osdep_handle h,
uint32_t count, int flags, int prot,
uint32_t *domids, uint32_t *refs,
diff --git a/tools/libxc/xc_netbsd_rumpkern.c b/tools/libxc/xc_netbsd_rumpkern.c
new file mode 100644
index 000..11d4a63
--- /dev/null
+++ b/tools/libxc/xc_netbsd_rumpkern.c
@@ -0,0 +1,62 @@
+/**
+ *
+ * Copyright 2013 Citrix.
+ * Use is subject to license terms.
+ *
+ * xc_gnttab functions:
+ * Copyright (c) 2007-2008, D G Murray derek.mur...@cl.cam.ac.uk
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ */
+
+#include xc_private.h
+
+#include xen/sys/evtchn.h
+#include unistd.h
+#include fcntl.h
+#include malloc.h
+#include sys/mman.h
+
+static struct xc_osdep_ops *rumpxen_osdep_init(xc_interface *xch,
+ enum xc_osdep_type type)
+{
+switch ( type )
+{
+case XC_OSDEP_PRIVCMD:
+return xc_privcmd_ops;
+case XC_OSDEP_EVTCHN:
+return xc_evtchn_ops;
+case XC_OSDEP_GNTTAB:
+return xc_gnttab_ops;
+default:
+return NULL;
+}
+}
+
+xc_osdep_info_t xc_osdep_info = {
+.name = Rump kernel OS interface,
+.init = rumpxen_osdep_init,
+.fake = 0,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode:
Re: [Xen-devel] [PATCH v4] libxl_set_memory_target: retain the same maxmem offset on top of the current target
On Wed, Feb 25, 2015 at 03:18:45PM +, Stefano Stabellini wrote:
In libxl_set_memory_target when setting the new maxmem, retain the same
offset on top of the current target. In the future the offset will
include memory allocated by QEMU for rom files.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
Changes in v4:
- remove new_target_memkb = 0 check.
Changes in v3:
- move call to libxl__uuid2string and libxl_dominfo_dispose earlier;
- error out if new_target_memkb = 0.
Changes in v2:
- remove LIBXL_MAXMEM_CONSTANT from LIBXL__LOG_ERRNO.
---
tools/libxl/libxl.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 52a783a..143cb3e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4681,6 +4681,12 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t
domid,
char *uuid;
xs_transaction_t t;
Should have:
libxl_dominfo_init(ptr);
+if (libxl_domain_info(ctx, ptr, domid) 0)
+goto out_no_transaction;
+
+uuid = libxl__uuid2string(gc, ptr.uuid);
+libxl_dominfo_dispose(ptr);
+
Since you need to use ptr later, you cannot dispose it here.
You can safely call dispose before returning to caller.
retry_transaction:
t = xs_transaction_start(ctx-xsh);
@@ -4756,7 +4762,7 @@ retry_transaction:
}
if (enforce) {
-memorykb = new_target_memkb + videoram;
+memorykb = ptr.max_memkb - current_target_memkb + new_target_memkb;
rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb);
if (rc != 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
@@ -4786,12 +4792,8 @@ retry_transaction:
goto out;
}
-libxl_dominfo_init(ptr);
-xcinfo2xlinfo(ctx, info, ptr);
If I'm not mistaken, info is only used here. I think you can delete
info and relevant code all together.
Wei.
-uuid = libxl__uuid2string(gc, ptr.uuid);
libxl__xs_write(gc, t, libxl__sprintf(gc, /vm/%s/memory, uuid),
%PRIu32, new_target_memkb / 1024);
-libxl_dominfo_dispose(ptr);
out:
if (!xs_transaction_end(ctx-xsh, t, abort_transaction)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen's Linux kernel config options
On Wed, 25 Feb 2015, Luis R. Rodriguez wrote:
On Wed, Feb 25, 2015 at 12:01:31PM +, Stefano Stabellini wrote:
On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Mon, 23 Feb 2015, Luis R. Rodriguez wrote:
On Thu, Feb 19, 2015 at 3:43 PM, Luis R. Rodriguez mcg...@suse.com
wrote:
On Fri, Dec 12, 2014 at 9:29 AM, David Vrabel
david.vra...@citrix.com wrote:
On 12/12/14 13:17, Juergen Gross wrote:
XEN_PVHVM
Move XEN_PVHVM under XEN and have it select PARAVIRT and
PARAVIRT_CLOCK.
FWIW, although it seems we do not want to let users just build
XEN_PVHVM hypervisors I have the changes required now to at least get
this to build so I do know what it takes.
XEN_FRONTENDXEN_PV ||
XEN_PVH ||
XEN_PVHVM
This enables all the basic infrastructure for frontends: event
channels,
grant tables and Xenbus.
Don't make XEN_FRONTEND depend on any XEN_* variant. It should be
possible to have frontend drivers without support for any of the
PV/PVHVM/PVH guest types.
David, can you elaborate on the type of Xen guest it would be on x86
its not PV, PVHVM, or PVH? I'm particularly curious about the
xen_domain_type and how it would end up to selected. As it is we tie
in XEN_PVHVM at build time with XEN_PVH, in order to have XEN_PVHVM
completely removed from XEN_PVH we need quite a bit of code changes
which at least as code exercise I have completed already. If we want
at the very least xen_domain_type set when XEN_PV, XEN_PVHVM, and
XEN_PVH are not available we need a bit more work.
OK I think I see the issue. We have nothing quite like
xen_guest_init() on x86 enlighten.c, we do have this for ARM and I
think I can that close the gap I'm observing.
Frontends only need event channels, grant
table and xenbus.
Well xenbus_probe_initcall() will check for xen_domain() and that
won't be set on x86 right now unless we have XEN_PV, XEN_PVHVM or
XEN_PVH set -- to start off with. Then
drivers/xen/xenbus/xenbus_client.c will check xen_feature in quite a
bit of places as well, that won't be set unless xen_setup_features()
is called which right now is only done on x86
arch/x86/xen/enlighten.c
which as Juergen pointed out, is not needed if you don't have XEN_PV
or XEN_PVH. As it turns out this is incorrect though, its needed for
XEN_PVHVM as well and my split exercise in code addresses this. Now,
at least in my code if you don't have XEN_PV, XEN_PVHVM, or XEN_PVH
we
don't call xen_setup_features() and its unclear to me where or how
that should happen in other cases.
Yeah I think having an x86 equivalent of xen_guest_init() would solve
this, Stefano, thoughts?
Having xen_guest_init() on x86 would be nice. Being able to set
xen_domain_type to XEN_HVM_DOMAIN if we are running on Xen, regardless
of XEN_PV/PVH/PVHVM also makes sense from Linux POV.
OK great, thanks for the feedback.
That said, I don't see much value in removing XEN_PVHVM: why are we even
doing this? What is the improvement we are seeking?
We would not, the above discussed about the possibility of letting
users enable XEN_PVHVM without XEN_PVH, that's all.
OK, that makes sense.
As is the only thing that can enable XEN_PVHVM is if you enable
XEN_PVH.
This is the bit that we need to change but it shouldn't be difficult.
If we want
xen_guest_init() alone though we might need the decoupling though at
least at build time so that if XEN_PV or XEN_PVH is not selected we'd
at least have XEN_PVHVM. Thoughts?
Today pv(h) and pvhvm have very different boot paths already: pv and pvh
initialize via xen_start_kernel while pvhvm via xen_hvm_guest_init.
Ah I see, this helps a lot thanks!
They are already very decoupled. You just need to make sure that
init_hvm_pv_info() is called regardless on any XEN_PV/PVH/PVHVM configs.
I'm a bit confused about this given that as I see it right now
init_hvm_pv_info() is the Xen x86_hyper-init_platform() callback and that is
only called on init_hypervisor_platform() *iff* x86_hyper-detect() passed
(returned non-zero), but xen detect() returns 0 in the PV case:
static uint32_t __init xen_hvm_platform(void)
{
if (xen_nopv)
return 0;
Re: [Xen-devel] Xen 4.5: can't create DomU guest on mustang(arm64)
On Thu, Feb 26, 2015 at 11:55 AM, Ming Lei tom.leim...@gmail.com wrote: Hi Guys, I just follow the guide in the link[1], and looks I can boot Dom0 successfully on mustang, and the xen 4.5 tools can be built OK on Dom0 side too. But when I try to create domU with the following commands: # losetup -f arm64-fs1.img # losetup -a /dev/loop0: [0802]:1318964 (/home/ubuntu/xt/arm64-fs1.img) # cat domu-test.cfg kernel = ./Image memory = 512 name = ubuntu vcpus = 2 disk = [ 'phy:/dev/loop0,xvda,w' ] extra = 'console=hvc0 root=/dev/xvda rw earlyprintk=xen' # /etc/init.d/xencommons start || true # echo 9 /proc/sysrq-trigger # export LIBXL_DEBUG_DUMP_DTB=guest.dtb # xl -vvv create domu-test.cfg I saw the failures in [2], so could anyone give a hand on it? I just figured out the reason: xen-block backend drvier isn't built in domU kernel. Once it is done, domU can be started successfully. Sorry for the noise. Thanks, Ming Lei ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [DOCSDAY PATCH] xen: rework the comments for struct xen_domctl_vnuma.
On Wed, Feb 25, 2015 at 04:33:17PM +0100, Dario Faggioli wrote:
In fact: vnode_to_pnode is an array, not a mask; there was a
typo in the one about vmemrange; there was no indication
of the data directions.
Signed-off-by: Dario Faggioli dario.faggi...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Keir Fraser k...@xen.org
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
xen/include/public/domctl.h | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index b3413a2..ad76853 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -958,27 +958,37 @@ typedef struct xen_domctl_vcpu_msrs
xen_domctl_vcpu_msrs_t;
DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpu_msrs_t);
#endif
-/*
- * Use in XEN_DOMCTL_setvnumainfo to set
- * vNUMA domain topology.
- */
+/* XEN_DOMCTL_setvnumainfo: specifies a virtual NUMA topology for the guest
*/
struct xen_domctl_vnuma {
+/* IN: number of vNUMA nodes to setup. Shall be greater than 0 */
uint32_t nr_vnodes;
+/* IN: number of memory ranges to setup */
uint32_t nr_vmemranges;
+/*
+ * IN: number of vCPUs of the domain (used as size of the vcpu_to_vnode
+ * array declared below). Shall be equal to the domain's max_vcpus.
+ */
uint32_t nr_vcpus;
-uint32_t pad;
+uint32_t pad; /* must be zero */
+
+/*
+ * IN: array for specifying the distances of the vNUMA nodes
+ * between each others. Shall have nr_vnodes*nr_vnodes elements.
+ */
XEN_GUEST_HANDLE_64(uint) vdistance;
+/*
+ * IN: array for specifying to what vNUMA node each vCPU
+ * belongs. Shall have nr_vcpus elements.
+ */
XEN_GUEST_HANDLE_64(uint) vcpu_to_vnode;
-
/*
- * vnodes to physical NUMA nodes mask.
- * This kept on per-domain basis for
- * interested consumers, such as numa aware ballooning.
+ * IN: array for specifying on what physical NUMA node
+ * each vNUMA node is placed. Shall have nr_vnodes elements.
*/
At the very least this hunk should be backported to 4.5?
XEN_GUEST_HANDLE_64(uint) vnode_to_pnode;
-
/*
- * memory rages for each vNUMA node
+ * IN: array for specifying the memory ranges.
+ * Shall have nr_vmemranges elements.
Inconsistent filling column setup? This line wraps at around 55
characters while others appear to be around 80. I think it might be
better to wrap around 72.
Wei.
*/
XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
};
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/5] libxc: minios: Introduce abstraction for files[]
On Thu, Feb 26, 2015 at 01:47:47PM +0100, Jürgen Groß wrote:
On 02/26/2015 12:56 PM, Wei Liu wrote:
From: Ian Jackson ian.jack...@eu.citrix.com
We are going to want to reuse this code for NetBSD rump kernels, where
there is no gntmap device and we just want to call the MiniOS gntmap
code directly.
As part of this we want to abstract away the use of files[] inside the
actual functions. Do this with a #define whose definition we are
going to make conditional in just a moment.
No functional change in this patch.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxc/xc_minios_privcmd.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/tools/libxc/xc_minios_privcmd.c
b/tools/libxc/xc_minios_privcmd.c
index 7766b86..27d9076 100644
--- a/tools/libxc/xc_minios_privcmd.c
+++ b/tools/libxc/xc_minios_privcmd.c
@@ -208,12 +208,14 @@ struct xc_osdep_ops xc_privcmd_ops = {
},
};
+#define GNTMAP(h) (files[(int)(h)].gntmap)
+
static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
{
int fd = alloc_fd(FTYPE_GNTMAP);
if ( fd == -1 )
return XC_OSDEP_OPEN_ERROR;
-gntmap_init(files[fd].gntmap);
+gntmap_init(GNTMAP(h));
GNTMAP(fd)?
Same multiple times below.
Good catch. I will fix this, thanks.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 3/5] xen/arm: Make gic-v2 code handle hip04-d01 platform
The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.
Use nr_lines to check for maximum irq supported. hip04-d01 support less
interrupts due to some field restriction. Any value above this is already
an error.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
Signed-off-by: Zoltan Kiss zoltan.k...@huawei.com
---
xen/arch/arm/Makefile | 3 +
xen/arch/arm/domain_build.c | 1 +
xen/arch/arm/gic-hip04.c| 351 ++--
xen/arch/arm/gic.c | 3 +-
xen/include/asm-arm/gic.h | 4 +
5 files changed, 188 insertions(+), 174 deletions(-)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 41aba2e..fad72d2 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -12,6 +12,9 @@ obj-y += domctl.o
obj-y += sysctl.o
obj-y += domain_build.o
obj-y += gic.o gic-v2.o
+ifeq (arm32,$(XEN_TARGET_ARCH))
+obj-$(HAS_NON_STANDARD_DRIVERS) += gic-hip04.o
+endif
obj-$(CONFIG_ARM_64) += gic-v3.o
obj-y += io.o
obj-y += irq.o
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c2dcb49..0834053 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1038,6 +1038,7 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
static const struct dt_device_match gic_matches[] __initconst =
{
DT_MATCH_GIC_V2,
+DT_MATCH_GIC_HIP04,
DT_MATCH_GIC_V3,
{ /* sentinel */ },
};
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index a401e3f..84d60fd 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -1,7 +1,8 @@
/*
- * xen/arch/arm/gic-v2.c
+ * xen/arch/arm/gic-hip04.c
*
- * ARM Generic Interrupt Controller support v2
+ * Generic Interrupt Controller for HiSilicon Hip04 platform
+ * Based heavily from gic-v2.c
*
* Tim Deegan t...@xen.org
* Copyright (c) 2011 Citrix Systems.
@@ -71,59 +72,66 @@ static struct {
void __iomem * map_hbase; /* IO Address of virtual interface registers */
paddr_t vbase;/* Address of virtual cpu interface registers */
spinlock_t lock;
-} gicv2;
+} hip04gic;
-static struct gic_info gicv2_info;
+static struct gic_info hip04gic_info;
/* The GIC mapping of CPU interfaces does not necessarily match the
* logical CPU numbering. Let's use mapping as returned by the GIC
* itself
*/
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
/* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+#define NR_GIC_CPU_IF 16
+
+#define HIP04_GICD_SGI_TARGET_SHIFT 8
static inline void writeb_gicd(uint8_t val, unsigned int offset)
{
-writeb_relaxed(val, gicv2.map_dbase + offset);
+writeb_relaxed(val, hip04gic.map_dbase + offset);
+}
+
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+writew_relaxed(val, hip04gic.map_dbase + offset);
}
static inline void writel_gicd(uint32_t val, unsigned int offset)
{
-writel_relaxed(val, gicv2.map_dbase + offset);
+writel_relaxed(val, hip04gic.map_dbase + offset);
}
static inline uint32_t readl_gicd(unsigned int offset)
{
-return readl_relaxed(gicv2.map_dbase + offset);
+return readl_relaxed(hip04gic.map_dbase + offset);
}
static inline void writel_gicc(uint32_t val, unsigned int offset)
{
unsigned int page = offset PAGE_SHIFT;
offset = ~PAGE_MASK;
-writel_relaxed(val, gicv2.map_cbase[page] + offset);
+writel_relaxed(val, hip04gic.map_cbase[page] + offset);
}
static inline uint32_t readl_gicc(unsigned int offset)
{
unsigned int page = offset PAGE_SHIFT;
offset = ~PAGE_MASK;
-return readl_relaxed(gicv2.map_cbase[page] + offset);
+return readl_relaxed(hip04gic.map_cbase[page] + offset);
}
static inline void writel_gich(uint32_t val, unsigned int offset)
{
-writel_relaxed(val, gicv2.map_hbase + offset);
+writel_relaxed(val, hip04gic.map_hbase + offset);
}
static inline uint32_t readl_gich(int unsigned offset)
{
-return readl_relaxed(gicv2.map_hbase + offset);
+return readl_relaxed(hip04gic.map_hbase + offset);
}
-static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
+static unsigned int hip04gic_cpu_mask(const cpumask_t *cpumask)
{
unsigned int cpu;
unsigned int mask = 0;
@@ -139,7 +147,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
return mask;
}
-static void gicv2_save_state(struct vcpu *v)
+static void hip04gic_save_state(struct vcpu *v)
{
int i;
@@ -147,7 +155,7 @@ static void gicv2_save_state(struct vcpu *v)
* this call and it only accesses struct vcpu fields that cannot be
* accessed simultaneously by another pCPU.
*/
-for ( i = 0; i gicv2_info.nr_lrs; i++ )
+for ( i = 0; i hip04gic_info.nr_lrs; i++ )
[Xen-devel] [PATCH v6 2/5] xen/arm: Add HAS_NON_STANDARD_DRIVERS build option to arm
Allow to enable non standard drivers in Xen. Can be override in .config file. Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com --- xen/arch/arm/Rules.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index c7bd227..4ed142a 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -11,6 +11,7 @@ HAS_VIDEO := y HAS_ARM_HDLCD := y HAS_PASSTHROUGH := y HAS_PDX := y +HAS_NON_STANDARD_DRIVERS ?= n CFLAGS += -I$(BASEDIR)/include -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 3/5] xen/arm: Make gic-v2 code handle hip04-d01 platform
Hi Frediano,
On 26/02/15 12:40, Frediano Ziglio wrote:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c2dcb49..0834053 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1038,6 +1038,7 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
static const struct dt_device_match gic_matches[] __initconst =
{
DT_MATCH_GIC_V2,
+DT_MATCH_GIC_HIP04,
DT_MATCH_GIC_V3,
{ /* sentinel */ },
};
I think this is the perfect time to introduce a callback to check if the
node is a GIC.
This would avoid to grow up this structure.
[..]
-static const char * const gicv2_dt_compat[] __initconst =
+static const char * const hip04gic_dt_compat[] __initconst =
{
-DT_COMPAT_GIC_CORTEX_A15,
-DT_COMPAT_GIC_CORTEX_A7,
-DT_COMPAT_GIC_400,
+DT_COMPAT_GIC_HIP04,
NULL
};
-DT_DEVICE_START(gicv2, GICv2:, DEVICE_GIC)
-.compatible = gicv2_dt_compat,
-.init = gicv2_init,
+DT_DEVICE_START(hip04gic, GIC-HIP04:, DEVICE_GIC)
The : was a mistake in the GICv2. Please don't reproduce it here.
+.compatible = hip04gic_dt_compat,
+.init = hip04gic_init,
DT_DEVICE_END
/*
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 390c8b0..e4512a8 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -565,12 +565,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum
gic_sgi sgi)
void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
{
unsigned int irq;
+unsigned int max_irq = gic_hw_ops-info-nr_lines;
do {
/* Reading IRQ will ACK it */
irq = gic_hw_ops-read_irq();
-if ( likely(irq = 16 irq 1021) )
+if ( likely(irq = 16 irq max_irq) )
{
local_irq_enable();
do_IRQ(regs, irq, is_fiq);
This change should belong to a separate patch.
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 187dc46..a36f486 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -160,6 +160,10 @@
DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
+#define DT_COMPAT_GIC_HIP04 hisilicon,hip04-intc
+
+#define DT_MATCH_GIC_HIP04 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
+
#define DT_COMPAT_GIC_V3 arm,gic-v3
#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_V3)
I would prefer if we avoid to add more compatibles like that in gic.h.
I have a patch to drop a part of this mess. I would advise your to use
cherry-pick the commit [1] in your branch.
[1]
http://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=commit;h=7ba87910e557b06c589c3c0fbc6757fa664d029e
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5.99.1 RFC 2/4] xen/arm: Make gic-v2 code handle hip04-d01 platform
2015-02-25 16:53 GMT+00:00 Stefano Stabellini
stefano.stabell...@eu.citrix.com:
On Wed, 25 Feb 2015, Frediano Ziglio wrote:
The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.
Use nr_lines to check for maximum irq supported. hip04-d01 support less
interrupts due to some field restriction. Any value above this is already
an error.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
Signed-off-by: Zoltan Kiss zoltan.k...@huawei.com
---
xen/arch/arm/domain_build.c | 1 +
xen/arch/arm/gic-hip04.c| 43 +--
xen/arch/arm/gic.c | 3 ++-
xen/include/asm-arm/gic.h | 3 +++
4 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c2dcb49..0834053 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1038,6 +1038,7 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
static const struct dt_device_match gic_matches[] __initconst =
{
DT_MATCH_GIC_V2,
+DT_MATCH_GIC_HIP04,
DT_MATCH_GIC_V3,
{ /* sentinel */ },
};
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index a401e3f..9a7ed46 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -1,7 +1,8 @@
/*
- * xen/arch/arm/gic-v2.c
+ * xen/arch/arm/gic-hip04.c
*
- * ARM Generic Interrupt Controller support v2
+ * ARM Generic Interrupt Controller support for HiSilicon Hip04 platform
+ * Based heavily from gic-v2.c
*
* Tim Deegan t...@xen.org
* Copyright (c) 2011 Citrix Systems.
@@ -79,16 +80,24 @@ static struct gic_info gicv2_info;
* logical CPU numbering. Let's use mapping as returned by the GIC
* itself
*/
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
/* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+#define NR_GIC_CPU_IF 16
+
+#undef GICD_SGI_TARGET_SHIFT
+#define GICD_SGI_TARGET_SHIFT 8
static inline void writeb_gicd(uint8_t val, unsigned int offset)
{
writeb_relaxed(val, gicv2.map_dbase + offset);
}
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+writew_relaxed(val, gicv2.map_dbase + offset);
+}
+
static inline void writel_gicd(uint32_t val, unsigned int offset)
{
writel_relaxed(val, gicv2.map_dbase + offset);
@@ -230,7 +239,7 @@ static void gicv2_set_irq_properties(struct irq_desc
*desc,
writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
/* Set target CPU mask (RAZ/WI on uniprocessor) */
-writeb_gicd(mask, GICD_ITARGETSR + irq);
+writew_gicd(mask, GICD_ITARGETSR + irq * 2);
/* Set priority */
writeb_gicd(priority, GICD_IPRIORITYR + irq);
@@ -244,8 +253,7 @@ static void __init gicv2_dist_init(void)
uint32_t gic_cpus;
int i;
-cpumask = readl_gicd(GICD_ITARGETSR) 0xff;
-cpumask |= cpumask 8;
+cpumask = readl_gicd(GICD_ITARGETSR) 0x;
cpumask |= cpumask 16;
/* Disable the distributor */
@@ -253,7 +261,7 @@ static void __init gicv2_dist_init(void)
type = readl_gicd(GICD_TYPER);
gicv2_info.nr_lines = 32 * ((type GICD_TYPE_LINES) + 1);
-gic_cpus = 1 + ((type GICD_TYPE_CPUS) 5);
+gic_cpus = 16;
printk(GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n,
gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? : s,
(type GICD_TYPE_SEC) ? , secure : ,
@@ -264,8 +272,8 @@ static void __init gicv2_dist_init(void)
writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
/* Route all global IRQs to this CPU */
-for ( i = 32; i gicv2_info.nr_lines; i += 4 )
-writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+for ( i = 32; i gicv2_info.nr_lines; i += 2 )
+writel_gicd(cpumask, GICD_ITARGETSR + (i / 2) * 4);
/* Default priority for global interrupts */
for ( i = 32; i gicv2_info.nr_lines; i += 4 )
@@ -285,7 +293,7 @@ static void __cpuinit gicv2_cpu_init(void)
{
int i;
-this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) 0xff;
+this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) 0x;
/* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
* even though they are controlled with GICD registers, they must
@@ -579,7 +587,7 @@ static void gicv2_irq_set_affinity(struct irq_desc
*desc, const cpumask_t *cpu_m
mask = gicv2_cpu_mask(cpu_mask);
/* Set target CPU mask (RAZ/WI on uniprocessor) */
-writeb_gicd(mask, GICD_ITARGETSR + desc-irq);
+writew_gicd(mask, GICD_ITARGETSR + desc-irq * 2);
spin_unlock(gicv2.lock);
}
@@ -765,19 +773,18 @@ static int __init gicv2_init(struct dt_device_node
*node, const void *data)
return 0;
}
-static const char
[Xen-devel] [PATCH] x86/traps: consolidate PV RDMSR emulation paths
Settle on just using one variable (val), and move the other into
WRMSR's local scope. Chain up further success paths to the
rdmsr_writeback label rather than open coding them.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2008,7 +2008,7 @@ static int emulate_privileged_op(struct
unsigned long code_base, code_limit;
char io_emul_stub[32];
void (*io_emul)(struct cpu_user_regs *) __attribute__((__regparm__(1)));
-uint64_t val, msr_content;
+uint64_t val;
if ( !read_descriptor(regs-cs, v, regs,
code_base, code_limit, ar,
@@ -2498,8 +2498,9 @@ static int emulate_privileged_op(struct
case 0x30: /* WRMSR */ {
uint32_t eax = regs-eax;
uint32_t edx = regs-edx;
-msr_content = ((uint64_t)edx 32) | eax;
-switch ( (u32)regs-ecx )
+uint64_t msr_content = ((uint64_t)edx 32) | eax;
+
+switch ( regs-_ecx )
{
case MSR_FS_BASE:
if ( is_pv_32on64_vcpu(v) )
@@ -2670,7 +2671,7 @@ static int emulate_privileged_op(struct
break;
case 0x32: /* RDMSR */
-switch ( (u32)regs-ecx )
+switch ( regs-_ecx )
{
case MSR_FS_BASE:
if ( is_pv_32on64_vcpu(v) )
@@ -2686,9 +2687,8 @@ static int emulate_privileged_op(struct
case MSR_SHADOW_GS_BASE:
if ( is_pv_32on64_vcpu(v) )
goto fail;
-regs-eax = v-arch.pv_vcpu.gs_base_user 0xUL;
-regs-edx = v-arch.pv_vcpu.gs_base_user 32;
-break;
+val = v-arch.pv_vcpu.gs_base_user;
+goto rdmsr_writeback;
case MSR_K7_FID_VID_CTL:
case MSR_K7_FID_VID_STATUS:
case MSR_K8_PSTATE_LIMIT:
@@ -2720,12 +2720,10 @@ static int emulate_privileged_op(struct
}
goto rdmsr_normal;
case MSR_IA32_MISC_ENABLE:
-if ( rdmsr_safe(regs-ecx, msr_content) )
+if ( rdmsr_safe(regs-ecx, val) )
goto fail;
-msr_content = guest_misc_enable(msr_content);
-regs-eax = (uint32_t)msr_content;
-regs-edx = (uint32_t)(msr_content 32);
-break;
+val = guest_misc_enable(val);
+goto rdmsr_writeback;
case MSR_AMD64_DR0_ADDRESS_MASK:
if ( !boot_cpu_has(X86_FEATURE_DBEXT) )
@@ -2743,12 +2741,7 @@ static int emulate_privileged_op(struct
default:
if ( rdmsr_hypervisor_regs(regs-ecx, val) )
-{
- rdmsr_writeback:
-regs-eax = (uint32_t)val;
-regs-edx = (uint32_t)(val 32);
-break;
-}
+goto rdmsr_writeback;
rc = vmce_rdmsr(regs-ecx, val);
if ( rc 0 )
@@ -2761,10 +2754,11 @@ static int emulate_privileged_op(struct
/* Everyone can read the MSR space. */
/* gdprintk(XENLOG_WARNING,Domain attempted RDMSR %p.\n,
_p(regs-ecx));*/
-if ( rdmsr_safe(regs-ecx, msr_content) )
+if ( rdmsr_safe(regs-ecx, val) )
goto fail;
-regs-eax = (uint32_t)msr_content;
-regs-edx = (uint32_t)(msr_content 32);
+ rdmsr_writeback:
+regs-eax = (uint32_t)val;
+regs-edx = (uint32_t)(val 32);
break;
}
break;
x86/traps: consolidate PV RDMSR emulation paths
Settle on just using one variable (val), and move the other into
WRMSR's local scope. Chain up further success paths to the
rdmsr_writeback label rather than open coding them.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2008,7 +2008,7 @@ static int emulate_privileged_op(struct
unsigned long code_base, code_limit;
char io_emul_stub[32];
void (*io_emul)(struct cpu_user_regs *) __attribute__((__regparm__(1)));
-uint64_t val, msr_content;
+uint64_t val;
if ( !read_descriptor(regs-cs, v, regs,
code_base, code_limit, ar,
@@ -2498,8 +2498,9 @@ static int emulate_privileged_op(struct
case 0x30: /* WRMSR */ {
uint32_t eax = regs-eax;
uint32_t edx = regs-edx;
-msr_content = ((uint64_t)edx 32) | eax;
-switch ( (u32)regs-ecx )
+uint64_t msr_content = ((uint64_t)edx 32) | eax;
+
+switch ( regs-_ecx )
{
case MSR_FS_BASE:
if ( is_pv_32on64_vcpu(v) )
@@ -2670,7 +2671,7 @@ static int emulate_privileged_op(struct
break;
case 0x32: /* RDMSR */
-switch ( (u32)regs-ecx )
+switch ( regs-_ecx )
{
case MSR_FS_BASE:
if ( is_pv_32on64_vcpu(v) )
@@ -2686,9 +2687,8 @@ static int emulate_privileged_op(struct
case MSR_SHADOW_GS_BASE:
if ( is_pv_32on64_vcpu(v) )
goto fail;
-
Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
On Wed, Feb 25, 2015 at 3:50 PM, Ian Campbell ian.campb...@citrix.com wrote: On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote: On 24/02/15 7:13 pm, Julien Grall wrote: On 24/02/15 00:23, Manish Jaggi wrote: Because you have to parse all the device tree to remove the reference to the second ITS. It's pointless and can be difficult to do it. Could you please describe the case where it is difficult You have to parse every node in the device tree and replace the msi-parent properties with only one ITS. Thats the idea. If you are able to emulate on ITS, you can do it for multiple one. keeping it simple and similar across dom0/domUs Consider a case where a domU is assigned two PCI devices which are attached to different nodes. (Node is an entity having its own cores are host controllers). The DOM0 view and guest view of the hardware are different. In the case of DOM0, we want to expose the same hardware layout as the host. So if there is 2 ITS then we should expose the 2 ITS. AFAIK Xen has a microkernel design and timer/mmu/smmu/gic/its are handled by xen and a virtualized interface is provided to the guest. So if none of SMMU in the layout of host is presented to dom0 the same can be valid for multiple ITS. SMMU is one of the things which Xen hides from dom0, for obvious reasons. Interrupts are exposed to dom0 in a 1:1 manner. AFAICT there is no reason for ITS to differ here. Since dom0 needs to be able to cope with being able to see all of the host host I/O devices (in the default no-passthrough case), it is possible, if not likely, that it will need the same amount of ITS resources (i.e. numbers of LPIs) as the host provides. In the case of the Guest, we (Xen) controls the memory layout. For Dom0 as well. Not true. For dom0 the memory layout is determined by the host memory layout. The MMIO regions are mapped through 1:1 and the RAM is a subset of the RAM regions of the host physical address space (often in 1:1, but with sufficient h/w support this need not be the case). Therefore we can expose only one ITS. If we follow 2 ITS in dom0 and 1 ITS in domU, how do u expect the Xen GIC ITS emulation driver to work. It should check that request came from a dom0 handle it differently. I think this would be *difficult*. I don't think so. If the vITS is written to handle multiple instances (i.e. in a modular way, as it should be) then it shouldn't matter whether any given domain has 1 or many vITS. The fact that dom0 may have one or more and domU only (currently) has one then becomes largely uninteresting. I have few queries 1) If Dom0 has 'n' ITS nodes, then how does Xen know which virtual ITS command Q is mapped to which Physical ITS command Q. In case of linux, the ITS node is added as msi chip to pci using of_pci_msi_chip_add() and from pci_dev structure we can know which ITS to use. But in case of Xen, when ITS command is trapped we have only dev_id info from ITS command. 2) If DomU is always given one virtual ITS node. If DomU is assinged with two different PCI devices connected to different physical ITS, then Xen vITS driver should know how to map PCI device to physical ITS For the two issues above, Xen should have mapping to pci segment and physical ITS node to use which can be queried by vITS driver and send command on to correct physical ITS Vijay ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] honor MEMF_no_refcount in alloc_heap_pages()
At 14:42 + on 25 Feb (1424871753), Jan Beulich wrote: Non-anonymous allocations with this flag set should - for the purpose of the availability check - be treated just like anonymous ones, as they wouldn't lead to a reduction of -outstanding_pages. Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Tim Deegan t...@xen.org --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -617,7 +617,8 @@ static struct page_info *alloc_heap_page */ if ( (outstanding_claims + request total_avail_pages + tmem_freeable_pages()) - (d == NULL || d-outstanding_pages request) ) + ((memflags MEMF_no_refcount) || + !d || d-outstanding_pages request) ) goto not_found; /* ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 0/5] xen/arm: Add support for Huawei hip04-d01 platform
Hi Frediano, On 26/02/15 12:40, Frediano Ziglio wrote: xen/arm: Make gic-v2 code handle hip04-d01 platform xen/arm: handle GICH register changes for hip04-d01 platform xen/arm: Force dom0 to use normal GICv2 driver on Hip04 platform There is not much benefits to have 3 separate patches. I think they could be merged in a single-patch. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
On Monday 23 February 2015 09:50 PM, Jan Beulich wrote: On 23.02.15 at 16:46, ian.campb...@citrix.com wrote: On Mon, 2015-02-23 at 15:27 +, Jan Beulich wrote: On 23.02.15 at 16:02, ian.campb...@citrix.com wrote: Is the reason for the scan being of segment 0 only is that it is the one which lives at the legacy PCI CFG addresses (or those magic I/O ports)? Right - ideally we would scan all segments, but we need Dom0 to tell us which MMCFG regions are safe to access, Is this done via PHYSDEVOP_pci_mmcfg_reserved? Yes. and hence can't do that scan at boot time. But we also won't get away without scanning, as we need to set up the IOMMU(s) to at least cover the devices used for booting the system. Which hopefully are all segment 0 or aren't needed until after dom0 tells Xen about them I suppose. Right. With EFI one may be able to overcome this one day, but the legacy BIOS doesn't even surface mechanisms (software interrupts) to access devices outside of segment 0. (All devices on segment zero are supposed to be accessible via config space access method 1.) Is that the legacy or magic ... again? Yes (just that there are two of them). Ian/Jan, Have you reached a conclusion? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5.99.1 RFC 1/4] xen/arm: Duplicate gic-v2.c file to support hip04 platform version
On Wed, 2015-02-25 at 16:59 +, Ian Campbell wrote:
I think we should disable the build of all drivers in Xen by default,
except for the ARM standard compliant ones (for aarch64 the SBSA is a
nice summary of what is considered compliant), to keep the size of the
binary small.
I don't think the SBSA is necessarily the best reference here, since it
only defines what is standardised within the scope of server
systems (whatever you take that to mean) and there are things which do
not fall under that umbrella.
That said I'm not sure what better reference there is.
Maybe even on non-server systems the set of hardware which Xen has to
drive itself is limited to things which are covered by the SBSA in
practice, by the nature of the fact that the majority of the wacky stuff
is driven from hardware domains.
So maybe SBSA is OK then...
Having thought about this overnight I'm now not so sure of this again, I
don't think SBSA is the definition we want.
Lets take a step back...
The set of hardware which Xen needs to be able to drive (rather than
give to a hardware domain) is:
* CPUs
* Host interrupt controllers
* Host timers
* A UART
* Second-state MMUs
* Second-stage SMMUs/IOMMU (First-stage used by domains)
* PCI host bridges (in the near future)
(did I forget any?)
NB: I'm only considering host level stuff here. Our virtualised hardware
as exposed to the guest is well defined right now and any conversation
about deviating from the set of hardware (e.g. providing a guest view to
a non-GIC compliant virtual interrupt controller) would be part of a
separate larger conversation about hvm style guests (and I'd, as you
might imagine, be very reluctant to code to Xen itself to support
non-standard vGICs in particular).
From a what does 'standards compliant' mean PoV we have:
CPUs:
Specified in the ARM ARM (v7=ARM DDI 0406, v8=ARM DDI 0487).
Uncontroversial, I hope!
Host interrupt controllers:
Defined in ARM Generic Interrupt Controller Architecture
Specification (v2=ARM IHI 0048B, v3=???).
Referenced from ARMv8 ARM (but not required AFAICT) but
nonetheless this is what we consider when we talk about the
standard interrupt controller.
Host timers:
Defined in the ARMv8 ARM Generic Timers chapter.
Defined as an extension to ARMv7 (don't have doc ref handy). For
our purposes such extensions are considered standardized[*].
UARTS:
SBSA defines some (pl011 only?), but there are lots, including
8250-alike ones (ns16550 etc) which is a well established
standard (from x86).
Given that UART drivers are generally small and pretty trivial I
think we can tolerate non-standard (i.e. non-SBSA, non-8250)
ones, so long as they are able to support our vuart interface.
I think the non-{pl011,8250} ones should be subject to non-core
(i.e. community) maintenance as I mentioned previously, i.e
should be listed in MAINTAINERS other than under the core ARM
entry. If we decide to go ahead with this approach I'll ask the
appropriate people to update MAINTAINERS.
Second stage MMU:
Defined in the ARMv8 ARM, or the ARMv7 LPAE extensions[*, **].
Second stage SMMU/IOMMU:
Defined in ARM System Memory Management Unit Architecture
Specification (ARM IHI 0062D?)
PCI host bridges:
We don't actually (properly) support PCI yet, but see my mails
in the Enhance platform support for PCI thread this morning,
for what we think the general shape might be taking.
The meaning of the PCI CFG (CAM, ECAM etc), MMIO and IO (MMIO
mapped) regions are, I think, all pretty well defined by the
(various?) PCI spec(s).
What's not quite so clear cut is the discovery of where the
controllers actually live (based on the fact that
Documentation/devicetree/bindings/pci/ has more than one entry
in it...).
SBSA doesn't really cover this either, it says The base address
of each ECAM region within the system memory map is
IMPLEMENTATION DEFINED and is expected to be discoverable from
system firmware data.
However I think it will be the case that most pci host bridge
drivers for Xen will end up being fairly trivial affairs, i.e.
parse the DT, perhaps a little bit of basic setup and register
the resulting regions with the PCI core and perhaps provide some
simple accessors.
So, I think we can say that for PCI controllers which export a
set of PCI standard CFG, MMIO, IO space regions (all as MMIO
mapped regions) and just require a specific driver for discovery
of the host bridge and small amounts of start of day
[Xen-devel] [PATCH 4/5] libxc: minios: Introduce abstraction for files[]
From: Ian Jackson ian.jack...@eu.citrix.com
We are going to want to reuse this code for NetBSD rump kernels, where
there is no gntmap device and we just want to call the MiniOS gntmap
code directly.
As part of this we want to abstract away the use of files[] inside the
actual functions. Do this with a #define whose definition we are
going to make conditional in just a moment.
No functional change in this patch.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxc/xc_minios_privcmd.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/tools/libxc/xc_minios_privcmd.c b/tools/libxc/xc_minios_privcmd.c
index 7766b86..27d9076 100644
--- a/tools/libxc/xc_minios_privcmd.c
+++ b/tools/libxc/xc_minios_privcmd.c
@@ -208,12 +208,14 @@ struct xc_osdep_ops xc_privcmd_ops = {
},
};
+#define GNTMAP(h) (files[(int)(h)].gntmap)
+
static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
{
int fd = alloc_fd(FTYPE_GNTMAP);
if ( fd == -1 )
return XC_OSDEP_OPEN_ERROR;
-gntmap_init(files[fd].gntmap);
+gntmap_init(GNTMAP(h));
return (xc_osdep_handle)fd;
}
@@ -225,7 +227,7 @@ static int minios_gnttab_close(xc_gnttab *xcg,
xc_osdep_handle h)
void minios_gnttab_close_fd(int fd)
{
-gntmap_fini(files[fd].gntmap);
+gntmap_fini(GNTMAP(h));
files[fd].type = FTYPE_NONE;
}
@@ -235,7 +237,6 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg,
xc_osdep_handle h,
uint32_t notify_offset,
evtchn_port_t notify_port)
{
-int fd = (int)h;
int stride = 1;
if (flags XC_GRANT_MAP_SINGLE_DOMAIN)
stride = 0;
@@ -243,7 +244,7 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg,
xc_osdep_handle h,
errno = ENOSYS;
return NULL;
}
-return gntmap_map_grant_refs(files[fd].gntmap,
+return gntmap_map_grant_refs(GNTMAP(h),
count, domids, stride,
refs, prot PROT_WRITE);
}
@@ -252,9 +253,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg,
xc_osdep_handle h,
void *start_address,
uint32_t count)
{
-int fd = (int)h;
int ret;
-ret = gntmap_munmap(files[fd].gntmap,
+ret = gntmap_munmap(GNTMAP(h),
(unsigned long) start_address,
count);
if (ret 0) {
@@ -267,9 +267,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg,
xc_osdep_handle h,
static int minios_gnttab_set_max_grants(xc_gnttab *xcg, xc_osdep_handle h,
uint32_t count)
{
-int fd = (int)h;
int ret;
-ret = gntmap_set_max_grants(files[fd].gntmap,
+ret = gntmap_set_max_grants(GNTMAP(h),
count);
if (ret 0) {
errno = -ret;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: remove LIBXL_MAXMEM_CONSTANT
On Wed, 25 Feb 2015, Don Slutz wrote:
On 02/25/15 10:07, Stefano Stabellini wrote:
LIBXL_MAXMEM_CONSTANT is used to increase the maxmem setting for a
domain by a constant amount. As it is not clear the reason why we should
be doing this, remove the constant.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
CC: mlati...@suse.com
CC: ian.campb...@citrix.com
---
I think that some sort of link to commit 901230f in QEMU:
commit 901230fd8ce053cc21312a2eca2f3ba9f1d103f2
Author: Stefano Stabellini stefano.stabell...@eu.citrix.com
Date: Wed Dec 3 08:15:19 2014 -0500
xen-hvm: increase maxmem before calling xc_domain_populate_physmap
Increase maxmem before calling xc_domain_populate_physmap_exact to
avoid the risk of running out of guest memory. This way we can also
avoid complex memory calculations in libxl at domain construction
time.
This patch fixes an abort() when assigning more than 4 NICs to a VM.
upstream-commit-id: c1d322e6048796296555dd36fdd102d7fa2f50bf
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Signed-off-by: Don Slutz dsl...@verizon.com
Because after this patch and without a correct QEMU, the number of
e1000 NICs a guest can use is less then 4.
That is true, in fact is not even a single emulated NIC in my tests.
I can either ask for a backport of
c1d322e6048796296555dd36fdd102d7fa2f50bf xen-hvm: increase maxmem
before calling xc_domain_populate_physmap to all QEMU stable branches,
or we just have to keep this around for now and maybe just add a comment
on why it is needed.
tools/libxl/libxl.c |9 -
tools/libxl/libxl_dom.c |3 +--
tools/libxl/libxl_internal.h |1 -
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b9a1941..9556a92 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4572,11 +4572,11 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t
domid, uint32_t max_memkb)
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, memory_static_max must be
greater than or or equal to memory_dynamic_max\n);
goto out;
}
-rc = xc_domain_setmaxmem(ctx-xch, domid, max_memkb +
LIBXL_MAXMEM_CONSTANT);
+rc = xc_domain_setmaxmem(ctx-xch, domid, max_memkb);
if (rc != 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
xc_domain_setmaxmem domid=%d memkb=%d failed
-rc=%d\n, domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
+rc=%d\n, domid, max_memkb, rc);
goto out;
}
@@ -4796,12 +4796,11 @@ retry_transaction:
if (enforce) {
memorykb = new_target_memkb + videoram;
-rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb +
-LIBXL_MAXMEM_CONSTANT);
+rc = xc_domain_setmaxmem(ctx-xch, domid, memorykb);
if (rc != 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
xc_domain_setmaxmem domid=%d memkb=%d failed
-rc=%d\n, domid, memorykb + LIBXL_MAXMEM_CONSTANT,
rc);
+rc=%d\n, domid, memorykb, rc);
abort_transaction = 1;
goto out;
}
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a16d4a1..923ba5c 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -408,8 +408,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
}
}
-if (xc_domain_setmaxmem(ctx-xch, domid, info-target_memkb +
-LIBXL_MAXMEM_CONSTANT) 0) {
+if (xc_domain_setmaxmem(ctx-xch, domid, info-target_memkb) 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, Couldn't set max memory);
return ERROR_FAIL;
}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 934465a..d5c5b68 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -89,7 +89,6 @@
#define LIBXL_QEMU_BODGE_TIMEOUT 2
#define LIBXL_XENCONSOLE_LIMIT 1048576
#define LIBXL_XENCONSOLE_PROTOCOL vt100
-#define LIBXL_MAXMEM_CONSTANT 1024
#define LIBXL_PV_EXTRA_MEMORY 1024
#define LIBXL_HVM_EXTRA_MEMORY 2048
#define LIBXL_MIN_DOM0_MEM (128*1024)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/5] libxc: Split off xc_minios_privcmd.c
Wei Liu, le Thu 26 Feb 2015 11:56:18 +, a écrit :
We are going to want to use some but not all of the machinery
previously in xc_minios.c. Split the privcmd and gnttab code into its
own file. This part is pure code motion.
But we also have to:
- Alter the Makefile to build and link xc_minios_privcmd.c too.
- Rename some of the minios_*_ops symbols to have proper namespaceing
and make them have external linkage, so that the init code (which
remains in xc_minios.c) can reference them.
- Call these *_ops symbols xc_*_ops so that we can mix and match in
the future. This does not impede the existing mechanisms for
run-time overriding. (But leave a comment next to the new
declarations in xc_private.h saying not to use these.)
- Change map_frames_ex to minios_map_frames_ex if compiling on rump
kernel.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
[ wei: wrap long lines, use __RUMPRUN__ and define macro for map_frames_ex ]
Signed-off-by: Wei Liu wei.l...@citrix.com
Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org
---
tools/libxc/Makefile| 2 +-
tools/libxc/xc_minios.c | 243 +
tools/libxc/xc_minios_privcmd.c | 291
tools/libxc/xc_private.h| 3 +
4 files changed, 299 insertions(+), 240 deletions(-)
create mode 100644 tools/libxc/xc_minios_privcmd.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 6fa88c7..4ace2b6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -47,7 +47,7 @@ CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
-CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
+CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_privcmd.c
GUEST_SRCS-y :=
GUEST_SRCS-y += xg_private.c xc_suspend.c
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index e703684..90e3363 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -41,164 +41,10 @@
#include xc_private.h
-void minios_interface_close_fd(int fd);
void minios_evtchn_close_fd(int fd);
-void minios_gnttab_close_fd(int fd);
-
-extern void minios_interface_close_fd(int fd);
-extern void minios_evtchn_close_fd(int fd);
extern struct wait_queue_head event_queue;
-static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
-{
-int fd = alloc_fd(FTYPE_XC);
-
-if ( fd == -1)
-return XC_OSDEP_OPEN_ERROR;
-
-return (xc_osdep_handle)fd;
-}
-
-static int minios_privcmd_close(xc_interface *xch, xc_osdep_handle h)
-{
-int fd = (int)h;
-return close(fd);
-}
-
-void minios_interface_close_fd(int fd)
-{
-files[fd].type = FTYPE_NONE;
-}
-
-static void *minios_privcmd_alloc_hypercall_buffer(xc_interface *xch,
xc_osdep_handle h, int npages)
-{
-return xc_memalign(xch, PAGE_SIZE, npages * PAGE_SIZE);
-}
-
-static void minios_privcmd_free_hypercall_buffer(xc_interface *xch,
xc_osdep_handle h, void *ptr, int npages)
-{
-free(ptr);
-}
-
-static int minios_privcmd_hypercall(xc_interface *xch, xc_osdep_handle h,
privcmd_hypercall_t *hypercall)
-{
-multicall_entry_t call;
-int i, ret;
-
-call.op = hypercall-op;
-for (i = 0; i ARRAY_SIZE(hypercall-arg); i++)
- call.args[i] = hypercall-arg[i];
-
-ret = HYPERVISOR_multicall(call, 1);
-
-if (ret 0) {
- errno = -ret;
- return -1;
-}
-if ((long) call.result 0) {
-errno = - (long) call.result;
-return -1;
-}
-return call.result;
-}
-
-static void *minios_privcmd_map_foreign_bulk(xc_interface *xch,
xc_osdep_handle h,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err,
unsigned int num)
-{
-unsigned long pt_prot = 0;
-if (prot PROT_READ)
- pt_prot = L1_PROT_RO;
-if (prot PROT_WRITE)
- pt_prot = L1_PROT;
-return map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
-}
-
-static void *minios_privcmd_map_foreign_batch(xc_interface *xch,
xc_osdep_handle h,
- uint32_t dom, int prot,
- xen_pfn_t *arr, int num)
-{
-unsigned long pt_prot = 0;
-int err[num];
-int i;
-unsigned long addr;
-
-if (prot PROT_READ)
- pt_prot = L1_PROT_RO;
-if (prot PROT_WRITE)
- pt_prot = L1_PROT;
-
-addr = (unsigned long) map_frames_ex(arr, num, 1, 0, 1, dom, err,
pt_prot);
-for (i = 0; i num; i++) {
-if (err[i])
-arr[i] |= 0xF000;
-}
-return (void *) addr;
-}
-
-static void *minios_privcmd_map_foreign_range(xc_interface *xch,
xc_osdep_handle
Re: [Xen-devel] [PATCH 2/5] libxc: Split off xc_minios_privcmd.c
On Thu, Feb 26, 2015 at 11:56:18AM +, Wei Liu wrote:
From: Ian Jackson ian.jack...@eu.citrix.com
We are going to want to use some but not all of the machinery
previously in xc_minios.c. Split the privcmd and gnttab code into its
own file. This part is pure code motion.
But we also have to:
- Alter the Makefile to build and link xc_minios_privcmd.c too.
- Rename some of the minios_*_ops symbols to have proper namespaceing
and make them have external linkage, so that the init code (which
remains in xc_minios.c) can reference them.
- Call these *_ops symbols xc_*_ops so that we can mix and match in
the future. This does not impede the existing mechanisms for
run-time overriding. (But leave a comment next to the new
declarations in xc_private.h saying not to use these.)
- Change map_frames_ex to minios_map_frames_ex if compiling on rump
kernel.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
[ wei: wrap long lines, use __RUMPRUN__ and define macro for map_frames_ex ]
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxc/Makefile| 2 +-
tools/libxc/xc_minios.c | 243 +
tools/libxc/xc_minios_privcmd.c | 291
tools/libxc/xc_private.h| 3 +
4 files changed, 299 insertions(+), 240 deletions(-)
create mode 100644 tools/libxc/xc_minios_privcmd.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 6fa88c7..4ace2b6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -47,7 +47,7 @@ CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
-CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
+CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_privcmd.c
GUEST_SRCS-y :=
GUEST_SRCS-y += xg_private.c xc_suspend.c
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index e703684..90e3363 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -41,164 +41,10 @@
#include xc_private.h
-void minios_interface_close_fd(int fd);
void minios_evtchn_close_fd(int fd);
-void minios_gnttab_close_fd(int fd);
-
-extern void minios_interface_close_fd(int fd);
-extern void minios_evtchn_close_fd(int fd);
extern struct wait_queue_head event_queue;
-static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
-{
-int fd = alloc_fd(FTYPE_XC);
-
-if ( fd == -1)
-return XC_OSDEP_OPEN_ERROR;
-
-return (xc_osdep_handle)fd;
-}
-
-static int minios_privcmd_close(xc_interface *xch, xc_osdep_handle h)
-{
-int fd = (int)h;
-return close(fd);
-}
-
-void minios_interface_close_fd(int fd)
-{
-files[fd].type = FTYPE_NONE;
-}
-
-static void *minios_privcmd_alloc_hypercall_buffer(xc_interface *xch,
xc_osdep_handle h, int npages)
-{
-return xc_memalign(xch, PAGE_SIZE, npages * PAGE_SIZE);
-}
-
-static void minios_privcmd_free_hypercall_buffer(xc_interface *xch,
xc_osdep_handle h, void *ptr, int npages)
-{
-free(ptr);
-}
-
-static int minios_privcmd_hypercall(xc_interface *xch, xc_osdep_handle h,
privcmd_hypercall_t *hypercall)
-{
-multicall_entry_t call;
-int i, ret;
-
-call.op = hypercall-op;
-for (i = 0; i ARRAY_SIZE(hypercall-arg); i++)
- call.args[i] = hypercall-arg[i];
-
-ret = HYPERVISOR_multicall(call, 1);
-
-if (ret 0) {
- errno = -ret;
- return -1;
-}
-if ((long) call.result 0) {
-errno = - (long) call.result;
-return -1;
-}
-return call.result;
-}
-
-static void *minios_privcmd_map_foreign_bulk(xc_interface *xch,
xc_osdep_handle h,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err,
unsigned int num)
-{
-unsigned long pt_prot = 0;
-if (prot PROT_READ)
- pt_prot = L1_PROT_RO;
-if (prot PROT_WRITE)
- pt_prot = L1_PROT;
-return map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
-}
-
-static void *minios_privcmd_map_foreign_batch(xc_interface *xch,
xc_osdep_handle h,
- uint32_t dom, int prot,
- xen_pfn_t *arr, int num)
-{
-unsigned long pt_prot = 0;
-int err[num];
-int i;
-unsigned long addr;
-
-if (prot PROT_READ)
- pt_prot = L1_PROT_RO;
-if (prot PROT_WRITE)
- pt_prot = L1_PROT;
-
-addr = (unsigned long) map_frames_ex(arr, num, 1, 0, 1, dom, err,
pt_prot);
-for (i = 0; i num; i++) {
-if (err[i])
-arr[i] |= 0xF000;
-}
-return (void *) addr;
-}
-
-static void *minios_privcmd_map_foreign_range(xc_interface *xch,
xc_osdep_handle h,
-
Re: [Xen-devel] Xen 4.5: can't create DomU guest on mustang(arm64)
On Thu, Feb 26, 2015 at 5:41 PM, Ming Lei tom.leim...@gmail.com wrote: On Thu, Feb 26, 2015 at 11:55 AM, Ming Lei tom.leim...@gmail.com wrote: Hi Guys, I just follow the guide in the link[1], and looks I can boot Dom0 successfully on mustang, and the xen 4.5 tools can be built OK on Dom0 side too. But when I try to create domU with the following commands: # losetup -f arm64-fs1.img # losetup -a /dev/loop0: [0802]:1318964 (/home/ubuntu/xt/arm64-fs1.img) # cat domu-test.cfg kernel = ./Image memory = 512 name = ubuntu vcpus = 2 disk = [ 'phy:/dev/loop0,xvda,w' ] extra = 'console=hvc0 root=/dev/xvda rw earlyprintk=xen' # /etc/init.d/xencommons start || true # echo 9 /proc/sysrq-trigger # export LIBXL_DEBUG_DUMP_DTB=guest.dtb # xl -vvv create domu-test.cfg I saw the failures in [2], so could anyone give a hand on it? I just figured out the reason: xen-block backend drvier isn't built in domU kernel. It should be dom0 kernel. Thanks, Ming Lei ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/5] libxc: minios: Introduce abstraction for files[]
Wei Liu, le Thu 26 Feb 2015 11:56:20 +, a écrit :
From: Ian Jackson ian.jack...@eu.citrix.com
We are going to want to reuse this code for NetBSD rump kernels, where
there is no gntmap device and we just want to call the MiniOS gntmap
code directly.
As part of this we want to abstract away the use of files[] inside the
actual functions. Do this with a #define whose definition we are
going to make conditional in just a moment.
No functional change in this patch.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org
---
tools/libxc/xc_minios_privcmd.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/tools/libxc/xc_minios_privcmd.c b/tools/libxc/xc_minios_privcmd.c
index 7766b86..27d9076 100644
--- a/tools/libxc/xc_minios_privcmd.c
+++ b/tools/libxc/xc_minios_privcmd.c
@@ -208,12 +208,14 @@ struct xc_osdep_ops xc_privcmd_ops = {
},
};
+#define GNTMAP(h) (files[(int)(h)].gntmap)
+
static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
{
int fd = alloc_fd(FTYPE_GNTMAP);
if ( fd == -1 )
return XC_OSDEP_OPEN_ERROR;
-gntmap_init(files[fd].gntmap);
+gntmap_init(GNTMAP(h));
return (xc_osdep_handle)fd;
}
@@ -225,7 +227,7 @@ static int minios_gnttab_close(xc_gnttab *xcg,
xc_osdep_handle h)
void minios_gnttab_close_fd(int fd)
{
-gntmap_fini(files[fd].gntmap);
+gntmap_fini(GNTMAP(h));
files[fd].type = FTYPE_NONE;
}
@@ -235,7 +237,6 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg,
xc_osdep_handle h,
uint32_t notify_offset,
evtchn_port_t notify_port)
{
-int fd = (int)h;
int stride = 1;
if (flags XC_GRANT_MAP_SINGLE_DOMAIN)
stride = 0;
@@ -243,7 +244,7 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg,
xc_osdep_handle h,
errno = ENOSYS;
return NULL;
}
-return gntmap_map_grant_refs(files[fd].gntmap,
+return gntmap_map_grant_refs(GNTMAP(h),
count, domids, stride,
refs, prot PROT_WRITE);
}
@@ -252,9 +253,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg,
xc_osdep_handle h,
void *start_address,
uint32_t count)
{
-int fd = (int)h;
int ret;
-ret = gntmap_munmap(files[fd].gntmap,
+ret = gntmap_munmap(GNTMAP(h),
(unsigned long) start_address,
count);
if (ret 0) {
@@ -267,9 +267,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg,
xc_osdep_handle h,
static int minios_gnttab_set_max_grants(xc_gnttab *xcg, xc_osdep_handle h,
uint32_t count)
{
-int fd = (int)h;
int ret;
-ret = gntmap_set_max_grants(files[fd].gntmap,
+ret = gntmap_set_max_grants(GNTMAP(h),
count);
if (ret 0) {
errno = -ret;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
--
Samuel
I am the ILOVEGNU signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public License.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 5/5] xen/arm: Force dom0 to use normal GICv2 driver on Hip04 platform
Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/gic-hip04.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index d96a29e..c90ea1e 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -598,17 +598,21 @@ static int hip04gic_make_dt_node(const struct domain *d,
const struct dt_device_node *node, void *fdt)
{
const struct dt_device_node *gic = dt_interrupt_controller;
-const void *compatible = NULL;
+const void *compatible;
u32 len;
const __be32 *regs;
int res = 0;
-compatible = dt_get_property(gic, compatible, len);
-if ( !compatible )
-{
-dprintk(XENLOG_ERR, Can't find compatible property for the gic
node\n);
-return -FDT_ERR_XEN(ENOENT);
-}
+/*
+ * Replace compatibility string with a standard one.
+ * dom0 will see a compatible GIC. This as GICC is compatible
+ * with standard one and GICD (emulated by Xen) is compatible
+ * to standard. Otherwise we should implement HIP04 GICD in
+ * the virtual GIC.
+ * This actually limit CPU number to 8 for dom0.
+ */
+compatible = DT_COMPAT_GIC_CORTEX_A15;
+len = strlen((char*) compatible) + 1;
res = fdt_begin_node(fdt, interrupt-controller);
if ( res )
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/5] libxc: Split off xc_minios_privcmd.c
From: Ian Jackson ian.jack...@eu.citrix.com
We are going to want to use some but not all of the machinery
previously in xc_minios.c. Split the privcmd and gnttab code into its
own file. This part is pure code motion.
But we also have to:
- Alter the Makefile to build and link xc_minios_privcmd.c too.
- Rename some of the minios_*_ops symbols to have proper namespaceing
and make them have external linkage, so that the init code (which
remains in xc_minios.c) can reference them.
- Call these *_ops symbols xc_*_ops so that we can mix and match in
the future. This does not impede the existing mechanisms for
run-time overriding. (But leave a comment next to the new
declarations in xc_private.h saying not to use these.)
- Change map_frames_ex to minios_map_frames_ex if compiling on rump
kernel.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
[ wei: wrap long lines, use __RUMPRUN__ and define macro for map_frames_ex ]
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxc/Makefile| 2 +-
tools/libxc/xc_minios.c | 243 +
tools/libxc/xc_minios_privcmd.c | 291
tools/libxc/xc_private.h| 3 +
4 files changed, 299 insertions(+), 240 deletions(-)
create mode 100644 tools/libxc/xc_minios_privcmd.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 6fa88c7..4ace2b6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -47,7 +47,7 @@ CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
-CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
+CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_privcmd.c
GUEST_SRCS-y :=
GUEST_SRCS-y += xg_private.c xc_suspend.c
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index e703684..90e3363 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -41,164 +41,10 @@
#include xc_private.h
-void minios_interface_close_fd(int fd);
void minios_evtchn_close_fd(int fd);
-void minios_gnttab_close_fd(int fd);
-
-extern void minios_interface_close_fd(int fd);
-extern void minios_evtchn_close_fd(int fd);
extern struct wait_queue_head event_queue;
-static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
-{
-int fd = alloc_fd(FTYPE_XC);
-
-if ( fd == -1)
-return XC_OSDEP_OPEN_ERROR;
-
-return (xc_osdep_handle)fd;
-}
-
-static int minios_privcmd_close(xc_interface *xch, xc_osdep_handle h)
-{
-int fd = (int)h;
-return close(fd);
-}
-
-void minios_interface_close_fd(int fd)
-{
-files[fd].type = FTYPE_NONE;
-}
-
-static void *minios_privcmd_alloc_hypercall_buffer(xc_interface *xch,
xc_osdep_handle h, int npages)
-{
-return xc_memalign(xch, PAGE_SIZE, npages * PAGE_SIZE);
-}
-
-static void minios_privcmd_free_hypercall_buffer(xc_interface *xch,
xc_osdep_handle h, void *ptr, int npages)
-{
-free(ptr);
-}
-
-static int minios_privcmd_hypercall(xc_interface *xch, xc_osdep_handle h,
privcmd_hypercall_t *hypercall)
-{
-multicall_entry_t call;
-int i, ret;
-
-call.op = hypercall-op;
-for (i = 0; i ARRAY_SIZE(hypercall-arg); i++)
- call.args[i] = hypercall-arg[i];
-
-ret = HYPERVISOR_multicall(call, 1);
-
-if (ret 0) {
- errno = -ret;
- return -1;
-}
-if ((long) call.result 0) {
-errno = - (long) call.result;
-return -1;
-}
-return call.result;
-}
-
-static void *minios_privcmd_map_foreign_bulk(xc_interface *xch,
xc_osdep_handle h,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err,
unsigned int num)
-{
-unsigned long pt_prot = 0;
-if (prot PROT_READ)
- pt_prot = L1_PROT_RO;
-if (prot PROT_WRITE)
- pt_prot = L1_PROT;
-return map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
-}
-
-static void *minios_privcmd_map_foreign_batch(xc_interface *xch,
xc_osdep_handle h,
- uint32_t dom, int prot,
- xen_pfn_t *arr, int num)
-{
-unsigned long pt_prot = 0;
-int err[num];
-int i;
-unsigned long addr;
-
-if (prot PROT_READ)
- pt_prot = L1_PROT_RO;
-if (prot PROT_WRITE)
- pt_prot = L1_PROT;
-
-addr = (unsigned long) map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
-for (i = 0; i num; i++) {
-if (err[i])
-arr[i] |= 0xF000;
-}
-return (void *) addr;
-}
-
-static void *minios_privcmd_map_foreign_range(xc_interface *xch,
xc_osdep_handle h,
- uint32_t dom,
- int size, int prot,
- unsigned long mfn)
-{
-unsigned
Re: [Xen-devel] [PATCH v3 1/3] x86/numa: Allow arbitrary value of PXM in PXM-node mapping
On Wed, 2015-02-25 at 18:41 -0500, Boris Ostrovsky wrote: ACPI defines proximity domain identifier as a 32-bit integer. While in most cases the values will be zero-based this is not guaranteed, making current pxm2node[256] mapping structure not appropriate. We will instead use MAX_NUMNODES-sized array of struct pxm2node to store PXM-to-node mapping. To accommodate common case of zero-based and contiguios PXMs we will, whenever possible, try to use PXM as index into this array array for fast lookups. ^array for fast lookups. Dario signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/5] NetBSDRump: provide evtchn.h
From: Ian Jackson ian.jack...@eu.citrix.com
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
[ wei: write commit message ]
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/include/xen-sys/NetBSDRump/evtchn.h | 86 +++
1 file changed, 86 insertions(+)
create mode 100644 tools/include/xen-sys/NetBSDRump/evtchn.h
diff --git a/tools/include/xen-sys/NetBSDRump/evtchn.h
b/tools/include/xen-sys/NetBSDRump/evtchn.h
new file mode 100644
index 000..2d8a1f9
--- /dev/null
+++ b/tools/include/xen-sys/NetBSDRump/evtchn.h
@@ -0,0 +1,86 @@
+/* $NetBSD: evtchn.h,v 1.1.1.1 2007/06/14 19:39:45 bouyer Exp $ */
+/**
+ * evtchn.h
+ *
+ * Interface to /dev/xen/evtchn.
+ *
+ * Copyright (c) 2003-2005, K A Fraser
+ *
+ * This file may be distributed separately from the Linux kernel, or
+ * incorporated into other software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __NetBSD_EVTCHN_H__
+#define __NetBSD_EVTCHN_H__
+
+/*
+ * Bind a fresh port to VIRQ @virq.
+ */
+#define IOCTL_EVTCHN_BIND_VIRQ \
+ _IOWR('E', 4, struct ioctl_evtchn_bind_virq)
+struct ioctl_evtchn_bind_virq {
+ unsigned int virq;
+ unsigned int port;
+};
+
+/*
+ * Bind a fresh port to remote @remote_domain, @remote_port.
+ */
+#define IOCTL_EVTCHN_BIND_INTERDOMAIN \
+ _IOWR('E', 5, struct ioctl_evtchn_bind_interdomain)
+struct ioctl_evtchn_bind_interdomain {
+ unsigned int remote_domain, remote_port;
+ unsigned int port;
+};
+
+/*
+ * Allocate a fresh port for binding to @remote_domain.
+ */
+#define IOCTL_EVTCHN_BIND_UNBOUND_PORT \
+ _IOWR('E', 6, struct ioctl_evtchn_bind_unbound_port)
+struct ioctl_evtchn_bind_unbound_port {
+ unsigned int remote_domain;
+ unsigned int port;
+};
+
+/*
+ * Unbind previously allocated @port.
+ */
+#define IOCTL_EVTCHN_UNBIND\
+ _IOW('E', 7, struct ioctl_evtchn_unbind)
+struct ioctl_evtchn_unbind {
+ unsigned int port;
+};
+
+/*
+ * Send event to previously allocated @port.
+ */
+#define IOCTL_EVTCHN_NOTIFY\
+ _IOW('E', 8, struct ioctl_evtchn_notify)
+struct ioctl_evtchn_notify {
+ unsigned int port;
+};
+
+/* Clear and reinitialise the event buffer. Clear error condition. */
+#define IOCTL_EVTCHN_RESET \
+ _IO('E', 9)
+
+#endif /* __NetBSD_EVTCHN_H__ */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/5] libxc: minios: Introduce abstraction for files[]
On 02/26/2015 12:56 PM, Wei Liu wrote:
From: Ian Jackson ian.jack...@eu.citrix.com
We are going to want to reuse this code for NetBSD rump kernels, where
there is no gntmap device and we just want to call the MiniOS gntmap
code directly.
As part of this we want to abstract away the use of files[] inside the
actual functions. Do this with a #define whose definition we are
going to make conditional in just a moment.
No functional change in this patch.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxc/xc_minios_privcmd.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/tools/libxc/xc_minios_privcmd.c b/tools/libxc/xc_minios_privcmd.c
index 7766b86..27d9076 100644
--- a/tools/libxc/xc_minios_privcmd.c
+++ b/tools/libxc/xc_minios_privcmd.c
@@ -208,12 +208,14 @@ struct xc_osdep_ops xc_privcmd_ops = {
},
};
+#define GNTMAP(h) (files[(int)(h)].gntmap)
+
static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
{
int fd = alloc_fd(FTYPE_GNTMAP);
if ( fd == -1 )
return XC_OSDEP_OPEN_ERROR;
-gntmap_init(files[fd].gntmap);
+gntmap_init(GNTMAP(h));
GNTMAP(fd)?
Same multiple times below.
Juergen
return (xc_osdep_handle)fd;
}
@@ -225,7 +227,7 @@ static int minios_gnttab_close(xc_gnttab *xcg,
xc_osdep_handle h)
void minios_gnttab_close_fd(int fd)
{
-gntmap_fini(files[fd].gntmap);
+gntmap_fini(GNTMAP(h));
files[fd].type = FTYPE_NONE;
}
@@ -235,7 +237,6 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg,
xc_osdep_handle h,
uint32_t notify_offset,
evtchn_port_t notify_port)
{
-int fd = (int)h;
int stride = 1;
if (flags XC_GRANT_MAP_SINGLE_DOMAIN)
stride = 0;
@@ -243,7 +244,7 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg,
xc_osdep_handle h,
errno = ENOSYS;
return NULL;
}
-return gntmap_map_grant_refs(files[fd].gntmap,
+return gntmap_map_grant_refs(GNTMAP(h),
count, domids, stride,
refs, prot PROT_WRITE);
}
@@ -252,9 +253,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg,
xc_osdep_handle h,
void *start_address,
uint32_t count)
{
-int fd = (int)h;
int ret;
-ret = gntmap_munmap(files[fd].gntmap,
+ret = gntmap_munmap(GNTMAP(h),
(unsigned long) start_address,
count);
if (ret 0) {
@@ -267,9 +267,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg,
xc_osdep_handle h,
static int minios_gnttab_set_max_grants(xc_gnttab *xcg, xc_osdep_handle h,
uint32_t count)
{
-int fd = (int)h;
int ret;
-ret = gntmap_set_max_grants(files[fd].gntmap,
+ret = gntmap_set_max_grants(GNTMAP(h),
count);
if (ret 0) {
errno = -ret;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 4/5] xen/arm: handle GICH register changes for hip04-d01 platform
The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/gic-hip04.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index 84d60fd..d96a29e 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -87,6 +87,9 @@ static DEFINE_PER_CPU(u16, gic_cpu_id);
#define HIP04_GICD_SGI_TARGET_SHIFT 8
+#define HIP04_GICH_APR 0x70
+#define HIP04_GICH_LR0x80
+
static inline void writeb_gicd(uint8_t val, unsigned int offset)
{
writeb_relaxed(val, hip04gic.map_dbase + offset);
@@ -156,9 +159,9 @@ static void hip04gic_save_state(struct vcpu *v)
* accessed simultaneously by another pCPU.
*/
for ( i = 0; i hip04gic_info.nr_lrs; i++ )
-v-arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+v-arch.gic.v2.lr[i] = readl_gich(HIP04_GICH_LR + i * 4);
-v-arch.gic.v2.apr = readl_gich(GICH_APR);
+v-arch.gic.v2.apr = readl_gich(HIP04_GICH_APR);
v-arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
/* Disable until next VCPU scheduled */
writel_gich(0, GICH_HCR);
@@ -169,9 +172,9 @@ static void hip04gic_restore_state(const struct vcpu *v)
int i;
for ( i = 0; i hip04gic_info.nr_lrs; i++ )
-writel_gich(v-arch.gic.v2.lr[i], GICH_LR + i * 4);
+writel_gich(v-arch.gic.v2.lr[i], HIP04_GICH_LR + i * 4);
-writel_gich(v-arch.gic.v2.apr, GICH_APR);
+writel_gich(v-arch.gic.v2.apr, HIP04_GICH_APR);
writel_gich(v-arch.gic.v2.vmcr, GICH_VMCR);
writel_gich(GICH_HCR_EN, GICH_HCR);
}
@@ -184,7 +187,7 @@ static void hip04gic_dump_state(const struct vcpu *v)
{
for ( i = 0; i hip04gic_info.nr_lrs; i++ )
printk( HW_LR[%d]=%x\n, i,
- readl_gich(GICH_LR + i * 4));
+ readl_gich(HIP04_GICH_LR + i * 4));
}
else
{
@@ -412,12 +415,12 @@ static void hip04gic_update_lr(int lr, const struct
pending_irq *p,
GICH_V2_LR_PHYSICAL_SHIFT);
}
-writel_gich(lr_reg, GICH_LR + lr * 4);
+writel_gich(lr_reg, HIP04_GICH_LR + lr * 4);
}
static void hip04gic_clear_lr(int lr)
{
-writel_gich(0, GICH_LR + lr * 4);
+writel_gich(0, HIP04_GICH_LR + lr * 4);
}
static int hip04gicv_setup(struct domain *d)
@@ -465,7 +468,7 @@ static void hip04gic_read_lr(int lr, struct gic_lr *lr_reg)
{
uint32_t lrv;
-lrv = readl_gich(GICH_LR + lr * 4);
+lrv = readl_gich(HIP04_GICH_LR + lr * 4);
lr_reg-pirq = (lrv GICH_V2_LR_PHYSICAL_SHIFT)
GICH_V2_LR_PHYSICAL_MASK;
lr_reg-virq = (lrv GICH_V2_LR_VIRTUAL_SHIFT) GICH_V2_LR_VIRTUAL_MASK;
lr_reg-priority = (lrv GICH_V2_LR_PRIORITY_SHIFT)
GICH_V2_LR_PRIORITY_MASK;
@@ -488,7 +491,7 @@ static void hip04gic_write_lr(int lr, const struct gic_lr
*lr_reg)
GICH_V2_LR_HW_SHIFT) |
((uint32_t)(lr_reg-grp GICH_V2_LR_GRP_MASK)
GICH_V2_LR_GRP_SHIFT) );
-writel_gich(lrv, GICH_LR + lr * 4);
+writel_gich(lrv, HIP04_GICH_LR + lr * 4);
}
static void hip04gic_hcr_status(uint32_t flag, bool_t status)
@@ -511,7 +514,7 @@ static unsigned int hip04gic_read_vmcr_priority(void)
static unsigned int hip04gic_read_apr(int apr_reg)
{
- return readl_gich(GICH_APR);
+ return readl_gich(HIP04_GICH_APR);
}
static void hip04gic_irq_enable(struct irq_desc *desc)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 1/5] xen/arm: Duplicate gic-v2.c file to support hip04 platform version
HiSilison Hip04 platform use a slightly different version.
This is just a verbatim copy of the file to workaround git
not fully supporting copy operation.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/gic-hip04.c | 788 +++
1 file changed, 788 insertions(+)
create mode 100644 xen/arch/arm/gic-hip04.c
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
new file mode 100644
index 000..a401e3f
--- /dev/null
+++ b/xen/arch/arm/gic-hip04.c
@@ -0,0 +1,788 @@
+/*
+ * xen/arch/arm/gic-v2.c
+ *
+ * ARM Generic Interrupt Controller support v2
+ *
+ * Tim Deegan t...@xen.org
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include xen/config.h
+#include xen/lib.h
+#include xen/init.h
+#include xen/mm.h
+#include xen/irq.h
+#include xen/sched.h
+#include xen/errno.h
+#include xen/softirq.h
+#include xen/list.h
+#include xen/device_tree.h
+#include xen/libfdt/libfdt.h
+#include asm/p2m.h
+#include asm/domain.h
+#include asm/platform.h
+#include asm/device.h
+
+#include asm/io.h
+#include asm/gic.h
+
+/*
+ * LR register definitions are GIC v2 specific.
+ * Moved these definitions from header file to here
+ */
+#define GICH_V2_LR_VIRTUAL_MASK0x3ff
+#define GICH_V2_LR_VIRTUAL_SHIFT 0
+#define GICH_V2_LR_PHYSICAL_MASK 0x3ff
+#define GICH_V2_LR_PHYSICAL_SHIFT 10
+#define GICH_V2_LR_STATE_MASK 0x3
+#define GICH_V2_LR_STATE_SHIFT 28
+#define GICH_V2_LR_PRIORITY_SHIFT 23
+#define GICH_V2_LR_PRIORITY_MASK 0x1f
+#define GICH_V2_LR_HW_SHIFT31
+#define GICH_V2_LR_HW_MASK 0x1
+#define GICH_V2_LR_GRP_SHIFT 30
+#define GICH_V2_LR_GRP_MASK0x1
+#define GICH_V2_LR_MAINTENANCE_IRQ (119)
+#define GICH_V2_LR_GRP1(130)
+#define GICH_V2_LR_HW (131)
+#define GICH_V2_LR_CPUID_SHIFT 9
+#define GICH_V2_VTR_NRLRGS 0x3f
+
+#define GICH_V2_VMCR_PRIORITY_MASK 0x1f
+#define GICH_V2_VMCR_PRIORITY_SHIFT 27
+
+/* Global state */
+static struct {
+paddr_t dbase;/* Address of distributor registers */
+void __iomem * map_dbase; /* IO mapped Address of distributor registers */
+paddr_t cbase;/* Address of CPU interface registers */
+void __iomem * map_cbase[2]; /* IO mapped Address of CPU interface
registers */
+paddr_t hbase;/* Address of virtual interface registers */
+void __iomem * map_hbase; /* IO Address of virtual interface registers */
+paddr_t vbase;/* Address of virtual cpu interface registers */
+spinlock_t lock;
+} gicv2;
+
+static struct gic_info gicv2_info;
+
+/* The GIC mapping of CPU interfaces does not necessarily match the
+ * logical CPU numbering. Let's use mapping as returned by the GIC
+ * itself
+ */
+static DEFINE_PER_CPU(u8, gic_cpu_id);
+
+/* Maximum cpu interface per GIC */
+#define NR_GIC_CPU_IF 8
+
+static inline void writeb_gicd(uint8_t val, unsigned int offset)
+{
+writeb_relaxed(val, gicv2.map_dbase + offset);
+}
+
+static inline void writel_gicd(uint32_t val, unsigned int offset)
+{
+writel_relaxed(val, gicv2.map_dbase + offset);
+}
+
+static inline uint32_t readl_gicd(unsigned int offset)
+{
+return readl_relaxed(gicv2.map_dbase + offset);
+}
+
+static inline void writel_gicc(uint32_t val, unsigned int offset)
+{
+unsigned int page = offset PAGE_SHIFT;
+offset = ~PAGE_MASK;
+writel_relaxed(val, gicv2.map_cbase[page] + offset);
+}
+
+static inline uint32_t readl_gicc(unsigned int offset)
+{
+unsigned int page = offset PAGE_SHIFT;
+offset = ~PAGE_MASK;
+return readl_relaxed(gicv2.map_cbase[page] + offset);
+}
+
+static inline void writel_gich(uint32_t val, unsigned int offset)
+{
+writel_relaxed(val, gicv2.map_hbase + offset);
+}
+
+static inline uint32_t readl_gich(int unsigned offset)
+{
+return readl_relaxed(gicv2.map_hbase + offset);
+}
+
+static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
+{
+unsigned int cpu;
+unsigned int mask = 0;
+cpumask_t possible_mask;
+
+cpumask_and(possible_mask, cpumask, cpu_possible_map);
+for_each_cpu( cpu, possible_mask )
+{
+ASSERT(cpu NR_GIC_CPU_IF);
+mask |= per_cpu(gic_cpu_id, cpu);
+}
+
+return mask;
+}
+
+static void gicv2_save_state(struct vcpu *v)
+{
+int i;
+
+/* No need for spinlocks here because interrupts are disabled around
+ * this call and it only accesses struct vcpu fields that cannot be
+ *
[Xen-devel] [PATCH v6 0/5] xen/arm: Add support for Huawei hip04-d01 platform
This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details). Changes from V5.99.1: - removed RFC again; - use different constants for hip04 instead of redefine standard ones; - comment compatible string change; - add an option to ARM to enable non standard drivers; - rename gicv2 to hip04gic to make clear this is not a standard gic. Changes from v5: - do not change gic-v2.c code but use a copy. To be considered RFC, to see if better to use copy or other techniques. Changes from v4: - rebased to new version; - removed patch for computing GIC addresses as it apply to all platforms; - removed patches to platform (cpu and system operations) as now they can use a bootwrapper which provide them. Changes from v3: - change the way regs property is computed for GICv2 (Julien Grall); - revert order of compaible names for GIC (Julien Grall). Changes from v2: - rewrote DTS fix patch (Ian Campbell); - use is_hip04 macro instead of doing explicit test (Julien Grall); - do not use quirks to distinguish this platform (Ian Cambell); - move some GIC constants to C files instead of header (Julien Grall); - minor changes (Julien Grall). Changes from v1: - style (Julien Grall); - make gicv2_send_SGI faster (Julien Grall); - cleanup correctly if hip04_smp_init fails (Julien Grall); - remove quirks using compatibility (Ian Campbell); - other minor suggestions by Julien Grall. Frediano Ziglio (5): xen/arm: Duplicate gic-v2.c file to support hip04 platform version xen/arm: Add HAS_NON_STANDARD_DRIVERS build option to arm xen/arm: Make gic-v2 code handle hip04-d01 platform xen/arm: handle GICH register changes for hip04-d01 platform xen/arm: Force dom0 to use normal GICv2 driver on Hip04 platform xen/arch/arm/Makefile | 3 + xen/arch/arm/Rules.mk | 1 + xen/arch/arm/domain_build.c | 1 + xen/arch/arm/gic-hip04.c| 800 xen/arch/arm/gic.c | 3 +- xen/include/asm-arm/gic.h | 4 + 6 files changed, 811 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/gic-hip04.c -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
On Thu, 2015-02-26 at 15:39 +0530, Manish Jaggi wrote:
Have you reached a conclusion?
My current thinking on how PCI for Xen on ARM should look is thus:
xen/arch/arm/pci.c:
New file, containing core PCI infrastructure for ARM. Includes:
pci_hostbridge_register(), which registers a host bridge:
Registration includes:
DT node pointer
CFG space address
pci_hostbridge_ops function table, which
contains e.g. cfg space read/write ops, perhaps
other stuff).
Function for setting the (segment,bus) for a given host bridge.
Lets say pci_hostbridge_setup(), the host bridge must have been
previously registered. Looks up the host bridge via CFG space
address and maps that to (segment,bus).
Functions for looking up host bridges by various keys as needed
(cfg base address, DT node, etc)
pci_init() function, called from somewhere appropriate in
setup.c which calls device_init(node, DEVICE_PCIHOST, NULL) (see
gic_init() for the shape of this)
Any other common helper functions for managing PCI devices, e.g.
for implementing PHYSDEVOP_*, which cannot be made properly
common (i.e. shared with x86).
xen/drivers/pci/host-*.c (or pci/host/*.c):
New files, one per supported PCI controller IP block. Each
should use the normal DT_DEVICE infrastructure for probing,
i.e.:
DT_DEVICE_START(foo, FOO, DEVICE_PCIHOST)
Probe function should call pci_hostbridge_register() for each
host bridge which the controller exposes.
xen/arch/arm/physdev.c:
Implements do_physdev_op handling PHYSDEVOP_*. Includes:
New hypercall subop PHYSDEVOP_pci_host_bridge_add:
As per 1424703761.27930.140.ca...@citrix.com which
calls pci_hostbridge_setup() to map the (segment,bus) to
a specific pci_hostbridge_ops (i.e. must have previously
been registered with pci_hostbridge_register(), else
error).
PHYSDEVOP_pci_device_add/remove: Implement existing hypercall
interface used by x86 for ARM.
This requires that PHYSDEVOP_pci_host_bridge_add has
been called for the (segment,bus) which it refers to,
otherwise error.
Looks up the host bridge and does whatever setup is
required plus e.g. calling of pci_add_device().
No doubt various other existing interfaces will need wiring up, e.g.
pci_conf_{read,write}* should lookup the host bridge ops struct and call
the associated method.
I'm sure the above must be incomplete, but I hope the general shape
makes sense?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/5] allow domain heap allocations to specify more than one NUMA node
... using struct domain as a container for passing the respective
affinity mask: Quite a number of allocations are domain specific, yet
not to be accounted for that domain. Introduce a flag suppressing the
accounting altogether (i.e. going beyond MEMF_no_refcount) and use it
right away in common code (x86 and IOMMU code will get adjusted
subsequently).
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1657,7 +1657,8 @@ gnttab_transfer(
struct page_info *new_page;
void *sp, *dp;
-new_page = alloc_domheap_page(NULL, MEMF_bits(max_bitsize));
+new_page = alloc_domheap_page(e, MEMF_no_owner |
+ MEMF_bits(max_bitsize));
if ( new_page == NULL )
{
gop.status = GNTST_address_too_big;
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -462,7 +462,8 @@ static long memory_exchange(XEN_GUEST_HA
/* Allocate a chunk's worth of anonymous output pages. */
for ( j = 0; j (1UL out_chunk_order); j++ )
{
-page = alloc_domheap_pages(NULL, exch.out.extent_order, memflags);
+page = alloc_domheap_pages(d, exch.out.extent_order,
+ MEMF_no_owner | memflags);
if ( unlikely(page == NULL) )
{
rc = -ENOMEM;
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1685,10 +1685,14 @@ struct page_info *alloc_domheap_pages(
ASSERT(!in_irq());
-bits = domain_clamp_alloc_bitsize(d, bits ? : (BITS_PER_LONG+PAGE_SHIFT));
+bits = domain_clamp_alloc_bitsize(memflags MEMF_no_owner ? NULL : d,
+ bits ? : (BITS_PER_LONG+PAGE_SHIFT));
if ( (zone_hi = min_t(unsigned int, bits_to_zone(bits), zone_hi)) == 0 )
return NULL;
+if ( memflags MEMF_no_owner )
+memflags |= MEMF_no_refcount;
+
if ( dma_bitsize ((dma_zone = bits_to_zone(dma_bitsize)) zone_hi) )
pg = alloc_heap_pages(dma_zone + 1, zone_hi, order, memflags, d);
@@ -1698,7 +1702,8 @@ struct page_info *alloc_domheap_pages(
memflags, d)) == NULL)) )
return NULL;
-if ( (d != NULL) assign_pages(d, pg, order, memflags) )
+if ( d !(memflags MEMF_no_owner)
+ assign_pages(d, pg, order, memflags) )
{
free_heap_pages(pg, order);
return NULL;
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -120,6 +120,8 @@ struct npfec {
#define MEMF_no_dma (1U_MEMF_no_dma)
#define _MEMF_exact_node 4
#define MEMF_exact_node (1U_MEMF_exact_node)
+#define _MEMF_no_owner5
+#define MEMF_no_owner(1U_MEMF_no_owner)
#define _MEMF_node8
#define MEMF_node_mask ((1U (8 * sizeof(nodeid_t))) - 1)
#define MEMF_node(n) n) + 1) MEMF_node_mask) _MEMF_node)
allow domain heap allocations to specify more than one NUMA node
... using struct domain as a container for passing the respective
affinity mask: Quite a number of allocations are domain specific, yet
not to be accounted for that domain. Introduce a flag suppressing the
accounting altogether (i.e. going beyond MEMF_no_refcount) and use it
right away in common code (x86 and IOMMU code will get adjusted
subsequently).
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1657,7 +1657,8 @@ gnttab_transfer(
struct page_info *new_page;
void *sp, *dp;
-new_page = alloc_domheap_page(NULL, MEMF_bits(max_bitsize));
+new_page = alloc_domheap_page(e, MEMF_no_owner |
+ MEMF_bits(max_bitsize));
if ( new_page == NULL )
{
gop.status = GNTST_address_too_big;
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -462,7 +462,8 @@ static long memory_exchange(XEN_GUEST_HA
/* Allocate a chunk's worth of anonymous output pages. */
for ( j = 0; j (1UL out_chunk_order); j++ )
{
-page = alloc_domheap_pages(NULL, exch.out.extent_order, memflags);
+page = alloc_domheap_pages(d, exch.out.extent_order,
+ MEMF_no_owner | memflags);
if ( unlikely(page == NULL) )
{
rc = -ENOMEM;
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1685,10 +1685,14 @@ struct page_info *alloc_domheap_pages(
ASSERT(!in_irq());
-bits = domain_clamp_alloc_bitsize(d, bits ? : (BITS_PER_LONG+PAGE_SHIFT));
+bits = domain_clamp_alloc_bitsize(memflags MEMF_no_owner ? NULL : d,
+ bits ? : (BITS_PER_LONG+PAGE_SHIFT));
if ( (zone_hi = min_t(unsigned int, bits_to_zone(bits), zone_hi)) == 0 )
return NULL;
+if ( memflags MEMF_no_owner )
+
Re: [Xen-devel] [PATCH 2/4] usb: Introduce Xen pvUSB frontend
On Thu, 2015-02-26 at 14:35 +0100, Juergen Gross wrote:
+
+ /* reset completion */
+ if ((info-ports[wIndex].status
USB_PORT_STAT_RESET) != 0
+ time_after_eq(jiffies,
info-ports[wIndex].timeout)) {
+ info-ports[wIndex].status |=
+ USB_PORT_STAT_C_RESET 16;
+ info-ports[wIndex].status =
~USB_PORT_STAT_RESET;
+
+ if (info-devices[wIndex].status !=
+ USB_STATE_NOTATTACHED) {
+ info-ports[wIndex].status |=
+ USB_PORT_STAT_ENABLE;
+ info-devices[wIndex].status =
+ USB_STATE_DEFAULT;
+ }
+
+ switch (info-devices[wIndex].speed) {
+ case USB_SPEED_LOW:
+ info-ports[wIndex].status |=
+ USB_PORT_STAT_LOW_SPEED;
+ break;
+ case USB_SPEED_HIGH:
+ info-ports[wIndex].status |=
+ USB_PORT_STAT_HIGH_SPEED;
+ break;
+ default:
+ break;
+ }
+ }
+
+ ((u16 *)buf)[0] =
cpu_to_le16(info-ports[wIndex].status);
+ ((u16 *)buf)[1] =
cpu_to_le16(info-ports[wIndex].status 16);
Why in two chunks?
Regards
Oliver
+ break;
--
Oliver Neukum oneu...@suse.de
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.3-testing test] 35333: FAIL
flight 35333 xen-4.3-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35333/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3) broken in 35226 REGR. vs. 34190 build-armhf-pvops3 host-install(3) broken in 35226 REGR. vs. 34190 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 7 windows-install fail pass in 35226 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 7 debian-installfail REGR. vs. 34190 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail like 34190 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 5 xen-boot fail never pass test-armhf-armhf-xl-sedf-pin 5 xen-boot fail never pass test-armhf-armhf-xl-sedf 5 xen-boot fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass test-armhf-armhf-xl-multivcpu 5 xen-boot fail never pass test-armhf-armhf-xl-midway5 xen-boot fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-armhf-armhf-libvirt 1 build-check(1)blocked in 35226 n/a test-armhf-armhf-xl-sedf-pin 1 build-check(1)blocked in 35226 n/a test-armhf-armhf-xl-sedf 1 build-check(1)blocked in 35226 n/a test-armhf-armhf-xl 1 build-check(1)blocked in 35226 n/a test-armhf-armhf-xl-credit2 1 build-check(1)blocked in 35226 n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked in 35226 n/a test-armhf-armhf-xl-midway1 build-check(1)blocked in 35226 n/a build-armhf-libvirt 1 build-check(1)blocked in 35226 n/a test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stopfail in 35226 never pass version targeted for testing: xen 9ebac5765496b34f15b2328f41c00f789ed6d712 baseline version: xen ef73de2a84a3042c3481c9a521e8e0c756b793f2 People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Boris Ostrovsky boris.ostrov...@oracle.com Ian Jackson ian.jack...@eu.citrix.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen
Re: [Xen-devel] [RFC] When to use domain creation flag or HVM param?
At 15:33 + on 26 Feb (1424961188), Julien Grall wrote: Hi, On 26/02/15 11:09, Lars Kurth wrote: Tim, Andrew, Jan, it seems as if we are slowly coming to some conclusion on this thread. If I am mistaken, I am wondering whether it would make sense to have an IRC meeting with all the involved stake-holders and report back to the list. I'm not sure where I should answer... We have a similar problem on ARM where we have arch-specific information (GIC version, number of interrupts) which changes between each domain. On Xen 4.5, we took the approach to create a separate DOMCTL for passing information. It has to be called before any VCPUs is created (DOMCTL_set_max_vcpus) and make the code more complicate to handle because we have to defer some domain initialization. I took another approach for Xen 4.6 based on Jan suggestion [1]. A v3 as been send recently [2] and we had some discussion about what is the best approach. This line (adding these immutable config options at create time) seems like a good one to me. For migration, we'd need a hypercall that lets the Xen tools extract the correct values to pass to the receiving Xen. Xen would fill in the actual values used for anything (like this GIC option) that was set to 'default' or 'don't care' on the initial create op. Andrew Cooper had some reasons why we might want to split this into a bare create op (which might do no more than allocate a domid) and a set-config op that would take these and all other immutable flags. I'm not wild for that but could be convinced either way -- I'll let him fill in the details. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 04/23] libxc: duplicate snippet to allocate p2m_host array
Currently all in tree code doesn't set the superpage flag, but Konrad
wants it retained for the moment.
As I'm going to change the p2m_host array allocation, duplicate the code
snippet to allocate p2m_host array in this patch, so that we retain the
behaviour in superpage case.
This patch introduces no functional change and it will make future patch
easier to review. Also removed one stray tab while I was there.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
CC: Konrad Wilk konrad.w...@oracle.com
---
tools/libxc/xc_dom_x86.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index bf06fe4..9dbaedb 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -772,15 +772,16 @@ int arch_setup_meminit(struct xc_dom_image *dom)
return rc;
}
-dom-p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) * dom-total_pages);
-if ( dom-p2m_host == NULL )
-return -EINVAL;
-
if ( dom-superpages )
{
int count = dom-total_pages SUPERPAGE_PFN_SHIFT;
xen_pfn_t extents[count];
+dom-p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) *
+ dom-total_pages);
+if ( dom-p2m_host == NULL )
+return -EINVAL;
+
DOMPRINTF(Populating memory with %d superpages, count);
for ( pfn = 0; pfn count; pfn++ )
extents[pfn] = pfn SUPERPAGE_PFN_SHIFT;
@@ -809,9 +810,13 @@ int arch_setup_meminit(struct xc_dom_image *dom)
return rc;
}
/* setup initial p2m */
+dom-p2m_host = xc_dom_malloc(dom, sizeof(xen_pfn_t) *
+ dom-total_pages);
+if ( dom-p2m_host == NULL )
+return -EINVAL;
for ( pfn = 0; pfn dom-total_pages; pfn++ )
dom-p2m_host[pfn] = pfn;
-
+
/* allocate guest memory */
for ( i = rc = allocsz = 0;
(i dom-total_pages) !rc;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Branch Trace Storage for guests and VPMUinitialization
On 02/26/2015 03:56 AM, Dietmar Hahn wrote: Am Mittwoch 25 Februar 2015, 11:31:31 schrieb Boris Ostrovsky: On 02/25/2015 10:12 AM, kevin.ma...@gdata.de wrote: -Ursprüngliche Nachricht- Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] Gesendet: Dienstag, 24. Februar 2015 18:13 An: Mayer, Kevin; xen-devel@lists.xen.org Betreff: Re: [Xen-devel] Branch Trace Storage for guests and VPMU initialization On 02/24/2015 10:27 AM, kevin.ma...@gdata.de wrote: Hi guys I`m trying to set up the BTS so that I can log the branches taken in the guest using Xen 4.4.1 with a WinXP SP3 guest on a Core i7 Sandy Bridge. I added the vpmu=bts boot parameter to my grub2 configuration and extended the libxl,libxc,domctl,… with an own command so that I can trigger the activation of the BTS whenever I want. I am not sure why you are doing all these changes to Xen code. BTS is supposed to be managed from the guest. For example, a Fedora HVM guest will produce this: [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# perf record -e branches:u -c 1 -d sleep 1 [ perf record: Woken up 3838 times to write data ] [ perf record: Captured and wrote 0.704 MB perf.data (~30756 samples) ] [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# perf script -f ip,addr,sym,dso,symoff --show-kernel-path 8167c347 native_irq_return_iret+0x0 (/proc/kcore) = 328c001590 [unknown] (/proc/kcore) 8167c347 native_irq_return_iret+0x0 (/proc/kcore) = 328c001590 [unknown] ([unknown]) 328c001593 [unknown] ([unknown]) = 328c004b70 [unknown] ([unknown]) ... I want to be able to log the taken branches (of the guest) without the need to modify the guest at all. This means I have to do all the logic in the hypervisor, or am I wrong? In that case, yes. But then you have to make sure that at least * you don't load guest's VPMU (or, at least, BTS-related registers) on context switch But you need to modify PMU registers when switching to/from the guest context to get PMU running. I was thinking that all BTS stuff can be controlled from dom0 and so we can use dom0's version of these registers. I didn't realize that DS_AREA would have to be accessed in guest's address space (and that DEBUGCTL is loaded from VMCS). Which is what I think I said in response to this message (which didn't show up on the list because Kevin accidentally dropped xen-devel). -boris I didn't think of using the VPMU stuff with modifying the context from outside the guest. * You don't send the interrupt to the guest (meaning that you will need to somehow inform dom0 of the BTS interrupt) and probably more. Essentially, you want dom0 to profile the guest. I have been working on patches that would allow that but they are still under review. In this command I do the following: I set up the memory region for the BTS Buffer and the DS Buffer Management Area using xzalloc_bytes I don't think you should be allocating BTS buffers in the hypervisor, they are in guest's memory. I agree. As I said I think this is where my main problem is at the moment. Is there any way I can allocate memory in the hypervisor in a way the guest can access it? I am not sure this is what you want since you seem to *not* want the guest to process the samples, right? But yes, you can. E.g. something like what map_vcpu_info() does. (I have no idea how you'd do this from Windows.) The DS buffer has to be mapped within the guests address space so the CPU running in guest context can access this area. Otherwise you get this triple fault. So I would think you need a mixture of writing some stuff in Windows and patching the hypervisor. Dietmar. Of course the guest must not be able to use this memory in its normal operations but just for BTS. Is this even possible? I am rather confused at the moment. :-D Then I write the pointer to the BTS Buffer into the DS Buffer Management Area at +0x0 and +0x8 (BTS Buffer Base and BTS Index) When I use vmx_msr_write_intercept to store the value in MSR_IA32_DS_AREA the host reboots (my idea is he tries to access a vpmu-struct that isn´t there in the current vcpu and panics). Who is trying to write to MSR_IA32_DS_AREA? The guest or dom0? I thought you said that you want dom0 to do sampling. Or are you trying to setup DS area from your guest and control it from dom0? I am somewhat confused. Can you post hypervisor log? (hard to say how helpful it will be without seeing your code changes though) Right after enabling the BTS I get a triple fault. hvm.c:1357:d2 Triple fault on VCPU0 - invoking HVM shutdown action 1. That's not host reboot, this is your guest dying. When I use a modified version of vmx_msr_write_intercept I don’t get any crashes as long as I don’t enable BTS and TR in the GUEST_IA32_DEBUGCTL (BTR works). When I enable the BTS (and TR) the guest crashes. I suppose he gets killed by the hypervisor for accessing forbidden memory. Possibly because DS area point to
[Xen-devel] [PATCH v6 13/23] libxc: indentation change to xc_hvm_build_x86.c
Move a while loop in xc_hvm_build_x86 one block to the right. No
functional change introduced.
Functional changes will be introduced in next patch.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Dario Faggioli dario.faggi...@citrix.com
Cc: Elena Ufimtseva ufimts...@gmail.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
tools/libxc/xc_hvm_build_x86.c | 153 ++---
1 file changed, 81 insertions(+), 72 deletions(-)
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..ecc3224 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -353,98 +353,107 @@ static int setup_guest(xc_interface *xch,
cur_pages = 0xc0;
stat_normal_pages = 0xc0;
-while ( (rc == 0) (nr_pages cur_pages) )
{
-/* Clip count to maximum 1GB extent. */
-unsigned long count = nr_pages - cur_pages;
-unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
-
-if ( count max_pages )
-count = max_pages;
-
-cur_pfn = page_array[cur_pages];
-
-/* Take care the corner cases of super page tails */
-if ( ((cur_pfn (SUPERPAGE_1GB_NR_PFNS-1)) != 0)
- (count (-cur_pfn (SUPERPAGE_1GB_NR_PFNS-1))) )
-count = -cur_pfn (SUPERPAGE_1GB_NR_PFNS-1);
-else if ( ((count (SUPERPAGE_1GB_NR_PFNS-1)) != 0)
- (count SUPERPAGE_1GB_NR_PFNS) )
-count = ~(SUPERPAGE_1GB_NR_PFNS - 1);
-
-/* Attemp to allocate 1GB super page. Because in each pass we only
- * allocate at most 1GB, we don't have to clip super page boundaries.
- */
-if ( ((count | cur_pfn) (SUPERPAGE_1GB_NR_PFNS - 1)) == 0
- /* Check if there exists MMIO hole in the 1GB memory range */
- !check_mmio_hole(cur_pfn PAGE_SHIFT,
- SUPERPAGE_1GB_NR_PFNS PAGE_SHIFT,
- mmio_start, mmio_size) )
+while ( (rc == 0) (nr_pages cur_pages) )
{
-long done;
-unsigned long nr_extents = count SUPERPAGE_1GB_SHIFT;
-xen_pfn_t sp_extents[nr_extents];
-
-for ( i = 0; i nr_extents; i++ )
-sp_extents[i] = page_array[cur_pages+(iSUPERPAGE_1GB_SHIFT)];
-
-done = xc_domain_populate_physmap(xch, dom, nr_extents,
SUPERPAGE_1GB_SHIFT,
- pod_mode, sp_extents);
-
-if ( done 0 )
-{
-stat_1gb_pages += done;
-done = SUPERPAGE_1GB_SHIFT;
-cur_pages += done;
-count -= done;
-}
-}
+/* Clip count to maximum 1GB extent. */
+unsigned long count = nr_pages - cur_pages;
+unsigned long max_pages = SUPERPAGE_1GB_NR_PFNS;
-if ( count != 0 )
-{
-/* Clip count to maximum 8MB extent. */
-max_pages = SUPERPAGE_2MB_NR_PFNS * 4;
if ( count max_pages )
count = max_pages;
-
-/* Clip partial superpage extents to superpage boundaries. */
-if ( ((cur_pfn (SUPERPAGE_2MB_NR_PFNS-1)) != 0)
- (count (-cur_pfn (SUPERPAGE_2MB_NR_PFNS-1))) )
-count = -cur_pfn (SUPERPAGE_2MB_NR_PFNS-1);
-else if ( ((count (SUPERPAGE_2MB_NR_PFNS-1)) != 0)
- (count SUPERPAGE_2MB_NR_PFNS) )
-count = ~(SUPERPAGE_2MB_NR_PFNS - 1); /* clip non-s.p. tail */
-
-/* Attempt to allocate superpage extents. */
-if ( ((count | cur_pfn) (SUPERPAGE_2MB_NR_PFNS - 1)) == 0 )
+
+cur_pfn = page_array[cur_pages];
+
+/* Take care the corner cases of super page tails */
+if ( ((cur_pfn (SUPERPAGE_1GB_NR_PFNS-1)) != 0)
+ (count (-cur_pfn (SUPERPAGE_1GB_NR_PFNS-1))) )
+count = -cur_pfn (SUPERPAGE_1GB_NR_PFNS-1);
+else if ( ((count (SUPERPAGE_1GB_NR_PFNS-1)) != 0)
+ (count SUPERPAGE_1GB_NR_PFNS) )
+count = ~(SUPERPAGE_1GB_NR_PFNS - 1);
+
+/* Attemp to allocate 1GB super page. Because in each pass
+ * we only allocate at most 1GB, we don't have to clip
+ * super page boundaries.
+ */
+if ( ((count | cur_pfn) (SUPERPAGE_1GB_NR_PFNS - 1)) == 0
+ /* Check if there exists MMIO hole in the 1GB memory
+ * range */
+ !check_mmio_hole(cur_pfn PAGE_SHIFT,
+ SUPERPAGE_1GB_NR_PFNS PAGE_SHIFT,
+ mmio_start, mmio_size) )
{
long done;
-unsigned long nr_extents = count SUPERPAGE_2MB_SHIFT;
+unsigned long nr_extents =
Re: [Xen-devel] [PATCH v2] RFC: Automatically check xen's public headers for C++ pitfalls.
On 26.02.15 at 17:28, t...@xen.org wrote: At 16:11 + on 26 Feb (1424963496), Tim Deegan wrote: Explicitly _not_ addressing the use of 'private' in various fields, since we'd previously decided not to fix that. BTW, ring.h is the only instance of that, so the extra diff to clear that up too is pretty small (see below). Not sure what people think about that though - it might be quite a PITA for downstream users of it, though they ought really to be using local copies so they can update in a controlled way. linux-2.6.18-xen.hg always having consumed them (almost) verbatim, I don't think we should break users not massaging the headers. I.e. at least make the field name conditional upon using C vs C++. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: xen config changes v4
On Thu, Feb 26, 2015 at 11:08:20AM +, Stefano Stabellini wrote: On Thu, 26 Feb 2015, David Vrabel wrote: On 26/02/15 04:59, Juergen Gross wrote: So we are again in the situation that pv-drivers always imply the pvops kernel (PARAVIRT selected). I started the whole Kconfig rework to eliminate this dependency. Yes. Can you produce a series that just addresses this one issue. In the absence of any concrete requirement for this big Kconfig reorg I I don't think it is helpful. I clearly missed some context as I didn't realize that this was the intended goal. Why do we want this? Please explain as it won't come for free. We have a few PV interfaces for HVM guests that need PARAVIRT in Linux in order to be used, for example pv_time_ops and HVMOP_pagetable_dying. They are critical performance improvements and from the interface perspective, small enough that doesn't make much sense having a separate KConfig option for them. In order to reach the goal above we necessarily need to introduce a differentiation in terms of PV on HVM guests in Linux: 1) basic guests with PV network, disk, etc but no PV timers, no HVMOP_pagetable_dying, no PV IPIs 2) full PV on HVM guests that have PV network, disk, timers, HVMOP_pagetable_dying, PV IPIs and anything else that makes sense. 2) is much faster than 1) on Xen and 2) is only a tiny bit slower than 1) on native x86 Also don't we shove 2) down hvm guests right now? Even when everything is built in I do not see how we opt out for HVM for 1) at run time right now. If this is true then the question of motivation for this becomes even stronger I think. Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 12/23] libxl: build, check and pass vNUMA info to Xen for PV guest
Transform the user supplied vNUMA configuration into libxl internal
representations, and finally libxc representations. Check validity of
the configuration along the line.
Signed-off-by: Wei Liu wei.l...@citrix.com
Reviewed-by: Dario Faggioli dario.faggi...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Dario Faggioli dario.faggi...@citrix.com
Cc: Elena Ufimtseva ufimts...@gmail.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
Changes in v6:
1. Use unsigned for some variables.
2. Variable name: bit - j.
Changes in v5:
1. Adapt to change of interface (ditching xc_vnuma_info).
Changes in v4:
1. Adapt to new interfaces.
Changes in v3:
1. Add more commit log.
---
tools/libxl/libxl_dom.c | 77 +
1 file changed, 77 insertions(+)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a16d4a1..b58a19b 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -515,6 +515,51 @@ retry_transaction:
return 0;
}
+static int set_vnuma_info(libxl__gc *gc, uint32_t domid,
+ const libxl_domain_build_info *info,
+ const libxl__domain_build_state *state)
+{
+int rc = 0;
+unsigned int i, nr_vdistance;
+unsigned int *vcpu_to_vnode, *vnode_to_pnode, *vdistance = NULL;
+
+vcpu_to_vnode = libxl__calloc(gc, info-max_vcpus,
+ sizeof(unsigned int));
+vnode_to_pnode = libxl__calloc(gc, info-num_vnuma_nodes,
+ sizeof(unsigned int));
+
+nr_vdistance = info-num_vnuma_nodes * info-num_vnuma_nodes;
+vdistance = libxl__calloc(gc, nr_vdistance, sizeof(unsigned int));
+
+for (i = 0; i info-num_vnuma_nodes; i++) {
+libxl_vnode_info *v = info-vnuma_nodes[i];
+int j;
+
+/* vnode to pnode mapping */
+vnode_to_pnode[i] = v-pnode;
+
+/* vcpu to vnode mapping */
+libxl_for_each_set_bit(j, v-vcpus)
+vcpu_to_vnode[j] = i;
+
+/* node distances */
+assert(info-num_vnuma_nodes == v-num_distances);
+memcpy(vdistance + (i * info-num_vnuma_nodes),
+ v-distances,
+ v-num_distances * sizeof(unsigned int));
+}
+
+if (xc_domain_setvnuma(CTX-xch, domid, info-num_vnuma_nodes,
+ state-num_vmemranges, info-max_vcpus,
+ state-vmemranges, vdistance,
+ vcpu_to_vnode, vnode_to_pnode) 0) {
+LOGE(ERROR, xc_domain_setvnuma failed);
+rc = ERROR_FAIL;
+}
+
+return rc;
+}
+
int libxl__build_pv(libxl__gc *gc, uint32_t domid,
libxl_domain_build_info *info, libxl__domain_build_state *state)
{
@@ -572,6 +617,38 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
dom-xenstore_domid = state-store_domid;
dom-claim_enabled = libxl_defbool_val(info-claim_mode);
+if (info-num_vnuma_nodes != 0) {
+unsigned int i;
+
+ret = libxl__vnuma_build_vmemrange_pv(gc, domid, info, state);
+if (ret) {
+LOGE(ERROR, cannot build vmemranges);
+goto out;
+}
+ret = libxl__vnuma_config_check(gc, info, state);
+if (ret) goto out;
+
+ret = set_vnuma_info(gc, domid, info, state);
+if (ret) goto out;
+
+dom-nr_vmemranges = state-num_vmemranges;
+dom-vmemranges = xc_dom_malloc(dom, sizeof(*dom-vmemranges) *
+dom-nr_vmemranges);
+
+for (i = 0; i dom-nr_vmemranges; i++) {
+dom-vmemranges[i].start = state-vmemranges[i].start;
+dom-vmemranges[i].end = state-vmemranges[i].end;
+dom-vmemranges[i].flags = state-vmemranges[i].flags;
+dom-vmemranges[i].nid = state-vmemranges[i].nid;
+}
+
+dom-nr_vnodes = info-num_vnuma_nodes;
+dom-vnode_to_pnode = xc_dom_malloc(dom, sizeof(*dom-vnode_to_pnode) *
+dom-nr_vnodes);
+for (i = 0; i info-num_vnuma_nodes; i++)
+dom-vnode_to_pnode[i] = info-vnuma_nodes[i].pnode;
+}
+
if ( (ret = xc_dom_boot_xen_init(dom, ctx-xch, domid)) != 0 ) {
LOGE(ERROR, xc_dom_boot_xen_init failed);
goto out;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
