[Xen-devel] [distros-debian-wheezy test] 44432: trouble: blocked/broken
flight 44432 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44432/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 4 capture-logs !broken [st=!broken!] build-armhf-pvops 4 capture-logs !broken [st=!broken!] Regressions which are regarded as allowable (not blocking): build-armhf 3 host-install(3) broken like 44409 build-armhf-pvops 3 host-install(3) broken like 44409 build-i3863 host-install(3) broken like 44409 build-i386-pvops 3 host-install(3) broken like 44409 build-amd64-pvops 3 host-install(3) broken like 44409 build-amd64 3 host-install(3) broken like 44409 Tests which did not succeed, but are not blocking: test-amd64-amd64-i386-wheezy-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-wheezy-netboot-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-amd64-wheezy-netboot-pygrub 1 build-check(1) blocked n/a test-amd64-i386-i386-wheezy-netboot-pvgrub 1 build-check(1) blocked n/a baseline version: flight 44409 jobs: build-amd64 broken build-armhf broken build-i386 broken build-amd64-pvopsbroken build-armhf-pvopsbroken build-i386-pvops broken test-amd64-amd64-amd64-wheezy-netboot-pvgrub blocked test-amd64-i386-i386-wheezy-netboot-pvgrub blocked test-amd64-i386-amd64-wheezy-netboot-pygrub blocked test-amd64-amd64-i386-wheezy-netboot-pygrub blocked sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86, locking: Remove ticket (spin)lock implementation
* Peter Zijlstra wrote: > My motivation was that people keep trying to send patches against the ticket > lock code... David did just today, and he's not the first. Yeah, let's just remove dead code ASAP. It's not like it's hard to add (back) new code, should the need arise. Thanks, Ingo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] vmx: VT-d posted-interrupt core logic handling
> -Original Message- > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] > Sent: Tuesday, May 17, 2016 9:27 PM > To: Wu, Feng > Cc: Tian, Kevin ; Jan Beulich ; > Andrew Cooper ; Dario Faggioli > ; David Vrabel ; > GeorgeDunlap ; Lars Kurth ; > George Dunlap ; Ian Jackson > ; xen-devel@lists.xen.org > Subject: Re: vmx: VT-d posted-interrupt core logic handling > > On Thu, Mar 10, 2016 at 01:36:34PM +, Wu, Feng wrote: > > > > > > > -Original Message- > > > From: Tian, Kevin > > > Sent: Thursday, March 10, 2016 6:06 PM > > > To: Jan Beulich > > > Cc: Andrew Cooper ; Dario Faggioli > > > ; David Vrabel ; > > > GeorgeDunlap ; Lars Kurth > ; > > > George Dunlap ; Ian Jackson > > > ; Wu, Feng ; xen- > > > de...@lists.xen.org; Konrad Rzeszutek Wilk > > > Subject: RE: vmx: VT-d posted-interrupt core logic handling > > > > > > > > > Hi, Jan, > > > > > > I'm thinking your earlier idea about evenly distributed list: > > > > > > -- > > > Ah, right, I think that limitation was named before, yet I've > > > forgotten about it again. But that only slightly alters the > > > suggestion: To distribute vCPU-s evenly would then require to > > > change their placement on the pCPU in the course of entering > > > blocked state. > > > -- > > > > > > Actually after more thinking, there is no hard requirement that > > > the vcpu must block on the pcpu which is configured in 'NDST' > > > of that vcpu's PI descriptor. What really matters, is that the > > > vcpu is added to the linked list of the very pcpu, then when PI > > > notification comes we can always find out the vcpu struct from > > > that pcpu's linked list. Of course one drawback of such placement > > > is additional IPI incurred in wake up path. > > > > > > Then one possible optimized policy within vmx_vcpu_block could > > > be: > > > > > > (Say PCPU1 which VCPU1 is currently blocked on) > > > - As long as the #vcpus in the linked list on PCPU1 is below a > > > threshold (say 16), add VCPU1 to the list. NDST set to PCPU1; > > > Upon PI notification on PCPU1, local linked list is searched to > > > find VCPU1 and then VCPU1 will be unblocked on PCPU1; > > > > > > - Otherwise, add VCPU1 to PCPU2 based on a simple distribution > > > algorithm (based on vcpu_id/vm_id). VCPU1 still blocks on PCPU1 > > > but NDST set to PCPU2. Upon notification on PCPU2, local linked > > > list is searched to find VCPU1 and then an IPI is sent to PCPU1 to > > > unblock VCPU1; > > > > > > Feng, do you see any overlook here? :-) > > > > Kevin, thanks for the suggestion, it sounds a good idea, I will think > > it a bit more and do some trials based on it. > > Hey! > > I am curious how the trials went? This feature is pretty awesome and > I am wondering what the next step is? Good to know that you are interested in this feature. However, I have been occupied by another things recently, I think I will continue this work some time later. Thanks, Feng > > Thanks! ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 94554: tolerable FAIL - PUSHED
flight 94554 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/94554/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-xsm 7 host-ping-check-xen fail in 94530 pass in 94554 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 94530 pass in 94554 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail in 94530 pass in 94554 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail pass in 94530 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94506 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 94506 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass version targeted for testing: qemuua257c741491ff1c3c192d13a89c136dd6401c54d baseline version: qemuuc98e7937119503d06dbb494b7e4806ec66a27df0 Last test of basis94506 2016-05-17 09:48:40 Z1 days Testing same since94530 2016-05-17 23:10:46 Z1 days2 attempts People who touched revisions under test: Alexander Yarygin Changlong Xie Christian Borntraeger Cornelia Huck Fan Zhang Hollis Blanchard Peter Maydell Stefan Hajnoczi xiaoqiang zhao Yi Min Zhao jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-a
Re: [Xen-devel] [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after initialized HVM domain
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 May 2016 07:04
> To: suravee.suthikulpa...@amd.com; Paul Durrant
> Cc: George Dunlap; xen-devel@lists.xen.org; Keir (Xen.org)
> Subject: Re: [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after
> initialized HVM domain
>
> >>> Suravee Suthikulpanit 05/19/16 7:22
> AM >>>
> >On 05/16/2016 03:19 AM, Paul Durrant wrote:
> >> >From:suravee.suthikulpa...@amd.com
> >> >Sent: 13 May 2016 20:37
> >>> >The guest_iommu_init() is currently called by the following code path:
> >>> >
> >>> > arch/x86/domain.c: arch_domain_create()
> >>> > ]- drivers/passthrough/iommu.c: iommu_domain_init()
> >>> > |- drivers/passthrough/amd/pci_amd_iommu.c:
> >>> >amd_iommu_domain_init();
> >>> > |- drivers/passthrough/amd/iommu_guest.c: guest_iommu_init()
> >>> >
> >>> >At this point, the hvm_domain_initialised() has not been
> >>> >called. So register_mmio_handler(), in guest_iommu_init(), silently
> fails.
> >>> >This patch moves the call to guest_iommu_init/destroy() into
> >>> >the svm_domain_intialise/_destroy() instead.
> >>> >
> >> That seems wrong. You're taking a call that currently comes via a jump
> table, i.e. an abstraction layer, and calling it directly. Is it possible,
> instead, to
> move the call to iommu_domain_init() later in arch_domain_create()? It
> seems odd, to me at least, that it's done before hvm_domain_initialise()
> anyway.
> >
> >Good point. I think I should be able to move iommu_domain_init() call to
> >go after hvm_domain_initialise() as the following.
> >
> >--- a/xen/arch/x86/domain.c
> >+++ b/xen/arch/x86/domain.c
> >@@ -625,24 +625,21 @@ int arch_domain_create(struct domain *d,
> unsigned
> >int domcr_flags,
> >
> >if ( (rc = init_domain_irq_mapping(d)) != 0 )
> >goto fail;
> >-
> >-if ( (rc = iommu_domain_init(d)) != 0 )
> >-goto fail;
> >}
> >spin_lock_init(&d->arch.e820_lock);
> >
> >if ( has_hvm_container_domain(d) )
> >{
> >if ( (rc = hvm_domain_initialise(d)) != 0 )
> >-{
> >-iommu_domain_destroy(d);
> >goto fail;
> >-}
> >}
> >else
> >/* 64-bit PV guest by default. */
> >d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
> >
> >+if ( !is_idle_domain(d) && (rc = iommu_domain_init(d)) != 0 )
> >+goto fail;
>
> This would in the error case fail to undo what hvm_domain_initialise() did.
> There was a fix very recently dealing with a similar issue. There really
> shouldn't be anything that can fail after hvm_domain_initialise().
Why is that? There are many failure paths within hvm_domain_initialise().
What's wrong with calling hvm_domain_destroy() to undo the whole thing?
(Although I do notice that the io_bitmap would appear to leak in that case...
but that looks like a bug to me).
> And I also
> can't see why both of you think iommu_domain_init() has to come later -
> that's a function affecting not just HVM guests.
>
Yes, I realise that. But the problem is that, in the HVM case, it calls
functions that make use of infrastructure that's initialized by
hvm_domain_initialise().
Paul
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Supporting consistency of vcpu_runstate_info across cpus
A guest kernel can use the vcpu_op hypercall sub-op VCPUOP_register_runstate_memory_area to get a copy of the vcpu_runstate_info of a vcpu mapped into its memory. As this structure has no update indicator it is only save to be read by the vcpu it is containing the runstate information of. Being able to read the runstate info of another cpu is required e.g. by the Linux kernel to be able to calculate vruntime: see http://lists.xen.org/archives/html/xen-devel/2016-05/msg01790.html I'd suggest to add an "update in progress" indicator in the highest bit of vcpu_runstate_info->state_entry_time as this structure element is already used to detect vcpu scheduling when vcpu_runstate_info is read by the owning vcpu. The question is how to enable setting this indicator, as the guest must be able to cope with it (I believe the Linux kernel would just run fine, but we can't be sure this is true for all guests). I see the following possible solutions: a) Introduce a new vcpu_op hypercall sub-op for mapping the vcpu_runstate_info with update indicator support (a guest supporting this would try the new sub-op first and could fall back to VCPUOP_register_runstate_memory_area in case of ENOSYS). b) Add a virtual MSR to switch on the feature (not being able to set the appropriate bit would indicate the feature not being available). This is the variant KVM is using. Does ARM have something like MSRs? c) Add another hypercall to switch on the feature (similar to XENVER_get_features we could have a XENVER_set_features). Any preferences? Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus
On 19/05/2016 08:53, Juergen Gross wrote: > A guest kernel can use the vcpu_op hypercall sub-op > VCPUOP_register_runstate_memory_area to get a copy of the > vcpu_runstate_info of a vcpu mapped into its memory. As this structure > has no update indicator it is only save to be read by the vcpu it is > containing the runstate information of. > > Being able to read the runstate info of another cpu is required e.g. > by the Linux kernel to be able to calculate vruntime: see > > http://lists.xen.org/archives/html/xen-devel/2016-05/msg01790.html > > I'd suggest to add an "update in progress" indicator in the highest > bit of vcpu_runstate_info->state_entry_time as this structure element is > already used to detect vcpu scheduling when vcpu_runstate_info is read > by the owning vcpu. > > The question is how to enable setting this indicator, as the guest must > be able to cope with it (I believe the Linux kernel would just run fine, > but we can't be sure this is true for all guests). > > I see the following possible solutions: > > a) Introduce a new vcpu_op hypercall sub-op for mapping the >vcpu_runstate_info with update indicator support (a guest supporting >this would try the new sub-op first and could fall back to >VCPUOP_register_runstate_memory_area in case of ENOSYS). > > b) Add a virtual MSR to switch on the feature (not being able to set the >appropriate bit would indicate the feature not being available). This >is the variant KVM is using. Does ARM have something like MSRs? > > c) Add another hypercall to switch on the feature (similar to >XENVER_get_features we could have a XENVER_set_features). > > Any preferences? However, irrespective of how you signal the request for new behaviour, you should see about using a lockless clock rather than a single bit, as a single bit can't indicate the case where a complete update has occurred between two samplings. This will probably require an extension to the current implementation, at which point you might be able to add a capability field as well. Alternatively, the easiest way will probably be to add a new VMASSIST, which allows the guest to opt into the new behaviour. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for 4.7] xen: sched: avoid races on time values read from NOW()
Hey Wei, Again, I'm using an otherwise unnecessary cover letter for my analysis about <>. :-) I'd say yes, because the patch fixes an actual bug, in the form of a rather subtle race condition, which was all but trivial to spot. I must say, though, that I've only found the bug guilty of being particularly nasty if we use Credit2. Actually, I'm quite sure it has an effect on RTDS too (although I did not trace that), but since both Credit2 and RTDS are still marked as experimental in 4.7, one may think it's not worthwhile putting in something like this to fix experimental only code. Just FYI, this bug is what was causing the issue I briefly chatted about on IRC with George, yesterday, i.e., it is what led Credit2 to emit (rather aggresively, actually) the debug printks showed here: http://pastebin.com/gzYrNST5 Well, TBF, Credit1 will certainly benefit from the fix as well, but Credit1 relies less than the other two schedulers on time and timestamps (and there isn't sampling-vs-locking inversion in its own code after all), so the impact is much smaller. The fix itself is certainly self contained, as it only touches scheduling, and the whay in which it alters generic scheduler code, is indeed straightforward, and hence low risk. So, given all this, my opinion is that we should consider it for 4.7. In any case (I mean, 4.7 or not), after it will hit staging, it should be backported. Thanks and Regards, Dario --- Dario Faggioli (1): xen: sched: avoid races on time values read from NOW() xen/common/sched_credit2.c |4 ++-- xen/common/sched_rt.c |7 +-- xen/common/schedule.c |4 +++- 3 files changed, 10 insertions(+), 5 deletions(-) -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: sched: avoid races on time values read from NOW()
or (even in cases where there is no race, e.g., outside
of Credit2) avoid using a time sample which may be rather
old, and hence stale.
In fact, we should only sample NOW() from _inside_
the critical region within which the value we read is
used. If we don't, in case we have to spin for a while
before entering the region, when actually using it:
1) we will use something that, at the veryy least, is
not really "now", because of the spinning,
2) if someone else sampled NOW() during a critical
region protected by the lock we are spinning on,
and if we compare the two samples when we get
inside our region, our one will be 'earlier',
even if we actually arrived later, which is a
race.
In Credit2, we see an instance of 2), in runq_tickle(),
when it is called by csched2_context_saved() as it samples
NOW() before acquiring the runq lock. This makes things
look like the time went backwards, and it confuses the
algorithm (there's even a d2printk() about it, which would
trigger all the time, if enabled).
In RTDS, something similar happens in repl_timer_handler(),
and there's another instance in schedule() (in generic code),
so fix these cases too.
While there, improve csched2_vcpu_wake() and and rt_vcpu_wake()
a little as well (removing a pointless initialization, and
moving the sampling a bit closer to its use). These two hunks
entail no further functional changes.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Meng Xu
Cc: Wei Liu
---
xen/common/sched_credit2.c |4 ++--
xen/common/sched_rt.c |7 +--
xen/common/schedule.c |4 +++-
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index f95e509..1933ff1 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1028,7 +1028,7 @@ static void
csched2_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
{
struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
-s_time_t now = 0;
+s_time_t now;
/* Schedule lock should be held at this point. */
@@ -1085,8 +1085,8 @@ static void
csched2_context_saved(const struct scheduler *ops, struct vcpu *vc)
{
struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
-s_time_t now = NOW();
spinlock_t *lock = vcpu_schedule_lock_irq(vc);
+s_time_t now = NOW();
BUG_ON( !is_idle_vcpu(vc) && svc->rqd != RQD(ops, vc->processor));
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index aa3ffd2..0946101 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -1198,7 +1198,7 @@ static void
rt_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
{
struct rt_vcpu * const svc = rt_vcpu(vc);
-s_time_t now = NOW();
+s_time_t now;
bool_t missed;
BUG_ON( is_idle_vcpu(vc) );
@@ -1225,6 +1225,7 @@ rt_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
* If a deadline passed while svc was asleep/blocked, we need new
* scheduling parameters (a new deadline and full budget).
*/
+now = NOW();
missed = ( now >= svc->cur_deadline );
if ( missed )
@@ -1394,7 +1395,7 @@ rt_dom_cntl(
* from the replq and does the actual replenishment.
*/
static void repl_timer_handler(void *data){
-s_time_t now = NOW();
+s_time_t now;
struct scheduler *ops = data;
struct rt_private *prv = rt_priv(ops);
struct list_head *replq = rt_replq(ops);
@@ -1406,6 +1407,8 @@ static void repl_timer_handler(void *data){
spin_lock_irq(&prv->lock);
+now = NOW();
+
/*
* Do the replenishment and move replenished vcpus
* to the temporary list to tickle.
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 80fea39..5e35310 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1320,7 +1320,7 @@ static void vcpu_periodic_timer_work(struct vcpu *v)
static void schedule(void)
{
struct vcpu *prev = current, *next = NULL;
-s_time_t now = NOW();
+s_time_t now;
struct scheduler *sched;
unsigned long*tasklet_work = &this_cpu(tasklet_work_to_do);
bool_ttasklet_work_scheduled = 0;
@@ -1355,6 +1355,8 @@ static void schedule(void)
lock = pcpu_schedule_lock_irq(cpu);
+now = NOW();
+
stop_timer(&sd->s_timer);
/* get policy-specific decision on scheduling... */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/HVM: fix forwarding of internally cached requests
On April 28, 2016 11:13 PM, Jan Beulich wrote: > >>> On 25.04.16 at 10:40, wrote: > > With other patches also in place, still not work. > > Jianzhong has been left and Quan will take over the task. > > May I ask for another try, with current tip of staging plus > http://lists.xenproject.org/archives/html/xen-devel/2016- > 04/msg03661.html > ? Jan, The same issue for rhel 6.4VM, which cannot initialize VF driver too.. the below is log of rhel 6.4 VM: .. igbvf: :00.04.0: Invalid MAC Address: 00:00:00:00:00:00 igbvf: probe of :00.04.0 failed with error -5 .. But when I tried to initialize VF MAC in Dom0 with e.g.: $ip link set eth0 vf 0 mac 00:1E:67:65:93:01 Then to create rhel 6.4 VM again, the VF is working for rhel 6.4 VM. I will ask QA team to help me verify it on win2k8 guest (I'm not sure whether the win2k8 network driver is working or not). Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus
On 19/05/16 10:09, Andrew Cooper wrote:
> On 19/05/2016 08:53, Juergen Gross wrote:
>> A guest kernel can use the vcpu_op hypercall sub-op
>> VCPUOP_register_runstate_memory_area to get a copy of the
>> vcpu_runstate_info of a vcpu mapped into its memory. As this structure
>> has no update indicator it is only save to be read by the vcpu it is
>> containing the runstate information of.
>>
>> Being able to read the runstate info of another cpu is required e.g.
>> by the Linux kernel to be able to calculate vruntime: see
>>
>> http://lists.xen.org/archives/html/xen-devel/2016-05/msg01790.html
>>
>> I'd suggest to add an "update in progress" indicator in the highest
>> bit of vcpu_runstate_info->state_entry_time as this structure element is
>> already used to detect vcpu scheduling when vcpu_runstate_info is read
>> by the owning vcpu.
>>
>> The question is how to enable setting this indicator, as the guest must
>> be able to cope with it (I believe the Linux kernel would just run fine,
>> but we can't be sure this is true for all guests).
>>
>> I see the following possible solutions:
>>
>> a) Introduce a new vcpu_op hypercall sub-op for mapping the
>>vcpu_runstate_info with update indicator support (a guest supporting
>>this would try the new sub-op first and could fall back to
>>VCPUOP_register_runstate_memory_area in case of ENOSYS).
>>
>> b) Add a virtual MSR to switch on the feature (not being able to set the
>>appropriate bit would indicate the feature not being available). This
>>is the variant KVM is using. Does ARM have something like MSRs?
>>
>> c) Add another hypercall to switch on the feature (similar to
>>XENVER_get_features we could have a XENVER_set_features).
>>
>> Any preferences?
>
> However, irrespective of how you signal the request for new behaviour,
> you should see about using a lockless clock rather than a single bit, as
> a single bit can't indicate the case where a complete update has
> occurred between two samplings. This will probably require an extension
> to the current implementation, at which point you might be able to add a
> capability field as well.
That's the reason I've chosen state_entry_time as the home for the new
bit. state_entry_time is guaranteed to change between two updates. So
the logic would look like the following:
do {
old_entry_time = READ_ONCE(r->state_entry_time);
rmb();
new_state = READ_ONCE(*r);
rmb();
} while (new_state.state_entry_time != old_entry_time ||
(old_entry_time >> 63));
> Alternatively, the easiest way will probably be to add a new VMASSIST,
> which allows the guest to opt into the new behaviour.
Aah, nice. Yes, this seems to be a sensible option.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after initialized HVM domain
>>> On 19.05.16 at 09:52, wrote:
>> >--- a/xen/arch/x86/domain.c
>> >+++ b/xen/arch/x86/domain.c
>> >@@ -625,24 +625,21 @@ int arch_domain_create(struct domain *d,
>> unsigned
>> >int domcr_flags,
>> >
>> >if ( (rc = init_domain_irq_mapping(d)) != 0 )
>> >goto fail;
>> >-
>> >-if ( (rc = iommu_domain_init(d)) != 0 )
>> >-goto fail;
>> >}
>> >spin_lock_init(&d->arch.e820_lock);
>> >
>> >if ( has_hvm_container_domain(d) )
>> >{
>> >if ( (rc = hvm_domain_initialise(d)) != 0 )
>> >-{
>> >-iommu_domain_destroy(d);
>> >goto fail;
>> >-}
>> >}
>> >else
>> >/* 64-bit PV guest by default. */
>> >d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
>> >
>> >+if ( !is_idle_domain(d) && (rc = iommu_domain_init(d)) != 0 )
>> >+goto fail;
>>
>> This would in the error case fail to undo what hvm_domain_initialise() did.
>> There was a fix very recently dealing with a similar issue. There really
>> shouldn't be anything that can fail after hvm_domain_initialise().
>
> Why is that? There are many failure paths within hvm_domain_initialise().
> What's wrong with calling hvm_domain_destroy() to undo the whole thing?
Well, I simply didn't check whether hvm_domain_destroy() would be
suitable to be called in that case, but yes, it looks like it would be.
> (Although I do notice that the io_bitmap would appear to leak in that case...
> but that looks like a bug to me).
That's a hardware domain only aspect, and failure to construct
the hardware domain would be fatal to the system anyway.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86, locking: Remove ticket (spin)lock implementation
On 18/05/16 19:43, Peter Zijlstra wrote: > > We've unconditionally used the queued spinlock for many releases now. > > Its time to remove the old ticket lock code. Xen parts: Acked-by: David Vrabel David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xenalyze: fix a spurious newline
On 19/05/16 05:04, Dario Faggioli wrote:
> in dump mode, when tracing context switches.
>
> Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
> ---
> tools/xentrace/xenalyze.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
> index b949986..01ead8b 100644
> --- a/tools/xentrace/xenalyze.c
> +++ b/tools/xentrace/xenalyze.c
> @@ -7655,7 +7655,7 @@ void sched_process(struct pcpu_info *p)
> printf(", was runnable for %u.%uus, ", r->rsince / 1000,
> r->rsince % 1000);
> if ( r->slice > 0 )
> -printf("next slice %u.%uus\n", r->slice / 1000,
> +printf("next slice %u.%uus", r->slice / 1000,
> r->slice % 1000);
> printf("\n");
> }
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] AMD IOMMU: Introduce support for IVHD block type 11h
>>> On 19.05.16 at 08:30, wrote:
> On 05/17/2016 09:25 AM, Jan Beulich wrote:
> On 13.05.16 at 21:54, wrote:
>>> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
>>> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
>>> [...]
>>> @@ -901,7 +911,7 @@ static int __init parse_ivhd_block(const struct
>>> acpi_ivrs_hardware *ivhd_block)
>>> ivhd_block->header.length, block_length, iommu);
>>> break;
>>> default:
>>> -AMD_IOMMU_DEBUG("IVHD Error: Invalid Device Type!\n");
>>> +AMD_IOMMU_DEBUG("IVHD Error: %s: Invalid Device Type!\n",
> __func__);
>>
>> Why?
>
> There are some duplicated error message (in get_last_bdf_ivhd() and
> parse_ivhd_block(). So, I just want to differentiate them a bit. But
> this is not a big deal. I can just get rid of this change.
In that case perhaps better to adjust the wording so the messages
become distinguishable?
>>> +{
>>> +AMD_IOMMU_DEBUG("IVRS Block: Found type %#x flags %#x len %#x
>>> id %#x\n",
>>> +ivrs_block->type, ivrs_block->flags,
>>> +ivrs_block->length, ivrs_block->device_id);
>>> +if ( ivrs_block->type > IVHD_HIGHEST_SUPPORT_TYPE )
>>> +break;
>>
>> Is there a requirement for the table elements to appear in numerical
>> order?
>
> That is not in the spec. Although it seems to the convention.
I.e. we shouldn't rely on it.
>> And anyway - this if() appears to be redundant with the
>> enclosing one.
>
> I am not sure what you mean by this comment. Could you please elaborate?
You've removed too much context, so here the code fragment
again:
if ( is_ivhd_block (ivrs_block->type) )
{
AMD_IOMMU_DEBUG("IVRS Block: Found type %#x flags %#x len %#x id
%#x\n",
ivrs_block->type, ivrs_block->flags,
ivrs_block->length, ivrs_block->device_id);
if ( ivrs_block->type > IVHD_HIGHEST_SUPPORT_TYPE )
with
#define is_ivhd_block(x) \
( x == ACPI_IVRS_TYPE_HARDWARE || \
x == ACPI_IVRS_TYPE_HARDWARE_11H )
That means if the outer if()'s condition is true, the inner if()'s one
can never be.
>>> +int __init amd_iommu_get_supported_ivhd_type(void)
>>> +{
>>> +if ( unlikely(acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) )
>>> +return -EPERM;
>>
>> This check appears out of the blue, and isn't being mentioned in
>> the description. Best would probably be to split it out, but at the
>> very least it needs to be (briefly) explained.
>
> This logic was actually duplicated from the
> amd_iommu_update_ivrs_mapping_acpi(). I believe this was added by the
>
> commit 992fdf6f46252a459c6b1b8d971b2c71f01460f8
> honor ACPI v4 FADT flags
>
> It might make more sense to pull this out to just check once in the
> amd_iommu_init() along with adding some explanation.
Does it actually need duplicating? I.e. doesn't the error that results
from amd_iommu_update_ivrs_mapping_acpi() (if the flag is clear)
not suffice?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after initialized HVM domain
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 May 2016 10:00
> To: Paul Durrant
> Cc: suravee.suthikulpa...@amd.com; George Dunlap; xen-
> de...@lists.xen.org; Keir (Xen.org)
> Subject: RE: [PATCH V2 2/2] svm: iommu: Only call guest_iommu_init() after
> initialized HVM domain
>
> >>> On 19.05.16 at 09:52, wrote:
> >> >--- a/xen/arch/x86/domain.c
> >> >+++ b/xen/arch/x86/domain.c
> >> >@@ -625,24 +625,21 @@ int arch_domain_create(struct domain *d,
> >> unsigned
> >> >int domcr_flags,
> >> >
> >> >if ( (rc = init_domain_irq_mapping(d)) != 0 )
> >> >goto fail;
> >> >-
> >> >-if ( (rc = iommu_domain_init(d)) != 0 )
> >> >-goto fail;
> >> >}
> >> >spin_lock_init(&d->arch.e820_lock);
> >> >
> >> >if ( has_hvm_container_domain(d) )
> >> >{
> >> >if ( (rc = hvm_domain_initialise(d)) != 0 )
> >> >-{
> >> >-iommu_domain_destroy(d);
> >> >goto fail;
> >> >-}
> >> >}
> >> >else
> >> >/* 64-bit PV guest by default. */
> >> >d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
> >> >
> >> >+if ( !is_idle_domain(d) && (rc = iommu_domain_init(d)) != 0 )
> >> >+goto fail;
> >>
> >> This would in the error case fail to undo what hvm_domain_initialise() did.
> >> There was a fix very recently dealing with a similar issue. There really
> >> shouldn't be anything that can fail after hvm_domain_initialise().
> >
> > Why is that? There are many failure paths within hvm_domain_initialise().
> > What's wrong with calling hvm_domain_destroy() to undo the whole
> thing?
>
> Well, I simply didn't check whether hvm_domain_destroy() would be
> suitable to be called in that case, but yes, it looks like it would be.
>
> > (Although I do notice that the io_bitmap would appear to leak in that
> case...
> > but that looks like a bug to me).
>
> That's a hardware domain only aspect, and failure to construct
> the hardware domain would be fatal to the system anyway.
>
Ok. No problem then.
Paul
> Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/HVM: fix forwarding of internally cached requests
>>> On 19.05.16 at 10:30, wrote: > On April 28, 2016 11:13 PM, Jan Beulich wrote: >> >>> On 25.04.16 at 10:40, wrote: >> > With other patches also in place, still not work. >> > Jianzhong has been left and Quan will take over the task. >> >> May I ask for another try, with current tip of staging plus >> http://lists.xenproject.org/archives/html/xen-devel/2016- >> 04/msg03661.html >> ? > > The same issue for rhel 6.4VM, which cannot initialize VF driver too.. the > below is log of rhel 6.4 VM: > .. > igbvf: :00.04.0: Invalid MAC Address: 00:00:00:00:00:00 > igbvf: probe of :00.04.0 failed with error -5 > .. > > But when I tried to initialize VF MAC in Dom0 with e.g.: > $ip link set eth0 vf 0 mac 00:1E:67:65:93:01 Makes things even more strange, as things work fine for me with SLE11 and SLE12 guests. But I have to admit that the "Invalid MAC Address" looks quite unrelated, i.e. is this perhaps some completely different problem you have? Again, considering that you have a repro (while I don't), the easiest would be to simply log all MSI-X related actions (there shouldn't be too many), to see where things go wrong. Such a log alone would maybe already allow me to do further investigation. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server.
Previously p2m type p2m_mmio_write_dm was introduced for write-
protected memory pages whose write operations are supposed to be
forwarded to and emulated by an ioreq server. Yet limitations of
rangeset restrict the number of guest pages to be write-protected.
This patch replaces the p2m type p2m_mmio_write_dm with a new name:
p2m_ioreq_server, which means this p2m type can be claimed by one
ioreq server, instead of being tracked inside the rangeset of ioreq
server. And a new memory type, HVMMEM_ioreq_server, is now used in
the HVMOP_set/get_mem_type interface to set/get this p2m type.
Patches following up will add the related HVMOP handling code which
map/unmap type p2m_ioreq_server to/from an ioreq server.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Acked-by: Tim Deegan
Acked-by: Andrew Cooper
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: George Dunlap
Cc: Tim Deegan
changes in v4:
- According to George's comments, move the HVMMEM_unused part
into a seperate patch(which has already been accepted);
- Removed George's Reviewed-by because of changes after v3.
- According to Wei Liu's comments, change the format of the commit
message.
changes in v3:
- According to Jan & George's comments, keep HVMMEM_mmio_write_dm
for old xen interface versions, and replace it with HVMMEM_unused
for xen interfaces newer than 4.7.0; For p2m_ioreq_server, a new
enum - HVMMEM_ioreq_server is introduced for the get/set mem type
interfaces;
- Add George's Reviewed-by and Acked-by from Tim & Andrew.
changes in v2:
- According to George Dunlap's comments, only rename the p2m type,
with no behavior changes.
---
xen/arch/x86/hvm/hvm.c | 9 ++---
xen/arch/x86/mm/p2m-ept.c | 2 +-
xen/arch/x86/mm/p2m-pt.c| 2 +-
xen/arch/x86/mm/shadow/multi.c | 2 +-
xen/include/asm-x86/p2m.h | 4 ++--
xen/include/public/hvm/hvm_op.h | 5 +++--
6 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 5040a5c..21bc45c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1857,7 +1857,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long
gla,
*/
if ( (p2mt == p2m_mmio_dm) ||
(npfec.write_access &&
- (p2m_is_discard_write(p2mt) || (p2mt == p2m_mmio_write_dm))) )
+ (p2m_is_discard_write(p2mt) || (p2mt == p2m_ioreq_server))) )
{
__put_gfn(p2m, gfn);
if ( ap2m_active )
@@ -5507,6 +5507,8 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
get_gfn_query_unlocked(d, a.pfn, &t);
if ( p2m_is_mmio(t) )
a.mem_type = HVMMEM_mmio_dm;
+else if ( t == p2m_ioreq_server )
+a.mem_type = HVMMEM_ioreq_server;
else if ( p2m_is_readonly(t) )
a.mem_type = HVMMEM_ram_ro;
else if ( p2m_is_ram(t) )
@@ -5537,7 +5539,8 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
[HVMMEM_ram_rw] = p2m_ram_rw,
[HVMMEM_ram_ro] = p2m_ram_ro,
[HVMMEM_mmio_dm] = p2m_mmio_dm,
-[HVMMEM_unused] = p2m_invalid
+[HVMMEM_unused] = p2m_invalid,
+[HVMMEM_ioreq_server] = p2m_ioreq_server
};
if ( copy_from_guest(&a, arg, 1) )
@@ -5586,7 +5589,7 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE_PARAM(void) arg)
}
if ( !p2m_is_ram(t) &&
(!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) &&
- (t != p2m_mmio_write_dm || a.hvmmem_type != HVMMEM_ram_rw) )
+ (t != p2m_ioreq_server || a.hvmmem_type != HVMMEM_ram_rw) )
{
put_gfn(d, pfn);
goto setmemtype_fail;
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 1ed5b47..a45a573 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -171,7 +171,7 @@ static void ept_p2m_type_to_flags(struct p2m_domain *p2m,
ept_entry_t *entry,
entry->a = entry->d = !!cpu_has_vmx_ept_ad;
break;
case p2m_grant_map_ro:
-case p2m_mmio_write_dm:
+case p2m_ioreq_server:
entry->r = 1;
entry->w = entry->x = 0;
entry->a = !!cpu_has_vmx_ept_ad;
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 3d80612..eabd2e3 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -94,7 +94,7 @@ static unsigned long p2m_type_to_flags(p2m_type_t t, mfn_t
mfn,
default:
return flags | _PAGE_NX_BIT;
case p2m_grant_map_ro:
-case p2m_mmio_write_dm:
+case p2m_ioreq_server:
return flags | P2M_BASE_FLAGS | _PAGE_NX_BIT;
case p2m_ram_ro:
case p2m_ram_logdirty:
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 428be37..b322293 100
[Xen-devel] [PATCH v4 0/3] x86/ioreq server: Introduce HVMMEM_ioreq_server mem type.
XenGT leverages ioreq server to track and forward the accesses to GPU I/O resources, e.g. the PPGTT(per-process graphic translation tables). Currently, ioreq server uses rangeset to track the BDF/ PIO/MMIO ranges to be emulated. To select an ioreq server, the rangeset is searched to see if the I/O range is recorded. However, number of ram pages to be tracked may exceed the upper limit of rangeset. Previously, one solution was proposed to refactor the rangeset, and extend its upper limit. However, after 12 rounds discussion, we have decided to drop this approach due to security concerns. Now this new patch series introduces a new mem type, HVMMEM_ioreq_server, and added hvm operations to let one ioreq server to claim its ownership of ram pages with this type. Accesses to a page of this type will be handled by the specified ioreq server directly. Yu Zhang (3): x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server. x86/ioreq server: Add new functions to get/set memory types. x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server. xen/arch/x86/hvm/emulate.c | 32 +++- xen/arch/x86/hvm/hvm.c | 346 +-- xen/arch/x86/hvm/ioreq.c | 41 + xen/arch/x86/mm/hap/nested_hap.c | 2 +- xen/arch/x86/mm/p2m-ept.c| 7 +- xen/arch/x86/mm/p2m-pt.c | 23 ++- xen/arch/x86/mm/p2m.c| 70 xen/arch/x86/mm/shadow/multi.c | 3 +- xen/include/asm-x86/hvm/ioreq.h | 2 + xen/include/asm-x86/p2m.h| 32 +++- xen/include/public/hvm/hvm_op.h | 38 - 11 files changed, 452 insertions(+), 144 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
let one ioreq server claim/disclaim its responsibility for the
handling of guest pages with p2m type p2m_ioreq_server. Users
of this HVMOP can specify which kind of operation is supposed
to be emulated in a parameter named flags. Currently, this HVMOP
only support the emulation of write operations. And it can be
easily extended to support the emulation of read ones if an
ioreq server has such requirement in the future.
For now, we only support one ioreq server for this p2m type, so
once an ioreq server has claimed its ownership, subsequent calls
of the HVMOP_map_mem_type_to_ioreq_server will fail. Users can also
disclaim the ownership of guest ram pages with p2m_ioreq_server, by
triggering this new HVMOP, with ioreq server id set to the current
owner's and flags parameter set to 0.
Note both HVMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server
are only supported for HVMs with HAP enabled.
Also note that only after one ioreq server claims its ownership
of p2m_ioreq_server, will the p2m type change to p2m_ioreq_server
be allowed.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Acked-by: Tim Deegan
---
Cc: Paul Durrant
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Tim Deegan
changes in v4:
- According to Paul's advice, add comments around the definition
of HVMMEM_iore_server in hvm_op.h.
- According to Wei Liu's comments, change the format of the commit
message.
changes in v3:
- Only support write emulation in this patch;
- Remove the code to handle race condition in hvmemul_do_io(),
- No need to reset the p2m type after an ioreq server has disclaimed
its ownership of p2m_ioreq_server;
- Only allow p2m type change to p2m_ioreq_server after an ioreq
server has claimed its ownership of p2m_ioreq_server;
- Only allow p2m type change to p2m_ioreq_server from pages with type
p2m_ram_rw, and vice versa;
- HVMOP_map_mem_type_to_ioreq_server interface change - use uint16,
instead of enum to specify the memory type;
- Function prototype change to p2m_get_ioreq_server();
- Coding style changes;
- Commit message changes;
- Add Tim's Acked-by.
changes in v2:
- Only support HAP enabled HVMs;
- Replace p2m_mem_type_changed() with p2m_change_entry_type_global()
to reset the p2m type, when an ioreq server tries to claim/disclaim
its ownership of p2m_ioreq_server;
- Comments changes.
---
xen/arch/x86/hvm/emulate.c | 32 --
xen/arch/x86/hvm/hvm.c | 63 ++--
xen/arch/x86/hvm/ioreq.c | 41 +++
xen/arch/x86/mm/hap/nested_hap.c | 2 +-
xen/arch/x86/mm/p2m-ept.c| 7 +++-
xen/arch/x86/mm/p2m-pt.c | 23 +
xen/arch/x86/mm/p2m.c| 70
xen/arch/x86/mm/shadow/multi.c | 3 +-
xen/include/asm-x86/hvm/ioreq.h | 2 ++
xen/include/asm-x86/p2m.h| 30 +++--
xen/include/public/hvm/hvm_op.h | 35 +++-
11 files changed, 289 insertions(+), 19 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index b9cac8e..4571294 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -100,6 +100,7 @@ static int hvmemul_do_io(
uint8_t dir, bool_t df, bool_t data_is_addr, uintptr_t data)
{
struct vcpu *curr = current;
+struct domain *currd = curr->domain;
struct hvm_vcpu_io *vio = &curr->arch.hvm_vcpu.hvm_io;
ioreq_t p = {
.type = is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO,
@@ -141,7 +142,7 @@ static int hvmemul_do_io(
(p.dir != dir) ||
(p.df != df) ||
(p.data_is_ptr != data_is_addr) )
-domain_crash(curr->domain);
+domain_crash(currd);
if ( data_is_addr )
return X86EMUL_UNHANDLEABLE;
@@ -178,8 +179,33 @@ static int hvmemul_do_io(
break;
case X86EMUL_UNHANDLEABLE:
{
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s;
+p2m_type_t p2mt;
+
+if ( is_mmio )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned long flags;
+
+s = p2m_get_ioreq_server(currd, &flags);
+
+if ( dir == IOREQ_WRITE &&
+ !(flags & P2M_IOREQ_HANDLE_WRITE_ACCESS) )
+s = NULL;
+}
+else
+s = hvm_select_ioreq_server(currd, &p);
+}
+else
+{
+p2mt = p2m_invalid;
+s = hvm_select_ioreq_server(currd, &p);
+}
/* If there is no suitable backing DM, just ignore accesses */
if
[Xen-devel] [PATCH v4 2/3] x86/ioreq server: Add new functions to get/set memory types.
For clarity this patch breaks the code to set/get memory types out
of do_hvm_op() into dedicated functions: hvmop_set/get_mem_type().
Also, for clarity, checks for whether a memory type change is allowed
are broken out into a separate function called by hvmop_set_mem_type().
There is no intentional functional change in this patch.
Signed-off-by: Paul Durrant
Signed-off-by: Yu Zhang
Reviewed-by: George Dunlap
Acked-by: Andrew Cooper
---
Cc: Jan Beulich
Cc: Andrew Cooper
changes in v4:
- According to Wei Liu's comments, change the format of the commit
message.
changes in v3:
- Add Andrew's Acked-by and George's Reviewed-by.
changes in v2:
- According to George Dunlap's comments, follow the "set rc /
do something / goto out" pattern in hvmop_get_mem_type().
---
xen/arch/x86/hvm/hvm.c | 288 +++--
1 file changed, 161 insertions(+), 127 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 21bc45c..346da97 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5287,6 +5287,61 @@ static int do_altp2m_op(
return rc;
}
+static int hvmop_get_mem_type(
+XEN_GUEST_HANDLE_PARAM(xen_hvm_get_mem_type_t) arg)
+{
+struct xen_hvm_get_mem_type a;
+struct domain *d;
+p2m_type_t t;
+int rc;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+d = rcu_lock_domain_by_any_id(a.domid);
+if ( d == NULL )
+return -ESRCH;
+
+rc = xsm_hvm_param(XSM_TARGET, d, HVMOP_get_mem_type);
+if ( rc )
+goto out;
+
+rc = -EINVAL;
+if ( !is_hvm_domain(d) )
+goto out;
+
+/*
+ * Use get_gfn query as we are interested in the current
+ * type, not in allocating or unsharing. That'll happen
+ * on access.
+ */
+get_gfn_query_unlocked(d, a.pfn, &t);
+if ( p2m_is_mmio(t) )
+a.mem_type = HVMMEM_mmio_dm;
+else if ( t == p2m_ioreq_server )
+a.mem_type = HVMMEM_ioreq_server;
+else if ( p2m_is_readonly(t) )
+a.mem_type = HVMMEM_ram_ro;
+else if ( p2m_is_ram(t) )
+a.mem_type = HVMMEM_ram_rw;
+else if ( p2m_is_pod(t) )
+a.mem_type = HVMMEM_ram_rw;
+else if ( p2m_is_grant(t) )
+a.mem_type = HVMMEM_ram_rw;
+else
+a.mem_type = HVMMEM_mmio_dm;
+
+rc = -EFAULT;
+if ( __copy_to_guest(arg, &a, 1) )
+goto out;
+rc = 0;
+
+ out:
+rcu_unlock_domain(d);
+
+return rc;
+}
+
/*
* Note that this value is effectively part of the ABI, even if we don't need
* to make it a formal part of it: A guest suspended for migration in the
@@ -5295,6 +5350,107 @@ static int do_altp2m_op(
*/
#define HVMOP_op_mask 0xff
+static bool_t hvm_allow_p2m_type_change(p2m_type_t old, p2m_type_t new)
+{
+if ( p2m_is_ram(old) ||
+ (p2m_is_hole(old) && new == p2m_mmio_dm) ||
+ (old == p2m_ioreq_server && new == p2m_ram_rw) )
+return 1;
+
+return 0;
+}
+
+static int hvmop_set_mem_type(
+XEN_GUEST_HANDLE_PARAM(xen_hvm_set_mem_type_t) arg,
+unsigned long *iter)
+{
+unsigned long start_iter = *iter;
+struct xen_hvm_set_mem_type a;
+struct domain *d;
+int rc;
+
+/* Interface types to internal p2m types */
+static const p2m_type_t memtype[] = {
+[HVMMEM_ram_rw] = p2m_ram_rw,
+[HVMMEM_ram_ro] = p2m_ram_ro,
+[HVMMEM_mmio_dm] = p2m_mmio_dm,
+[HVMMEM_unused] = p2m_invalid,
+[HVMMEM_ioreq_server] = p2m_ioreq_server
+};
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+rc = rcu_lock_remote_domain_by_id(a.domid, &d);
+if ( rc != 0 )
+return rc;
+
+rc = -EINVAL;
+if ( !is_hvm_domain(d) )
+goto out;
+
+rc = xsm_hvm_control(XSM_DM_PRIV, d, HVMOP_set_mem_type);
+if ( rc )
+goto out;
+
+rc = -EINVAL;
+if ( a.nr < start_iter ||
+ ((a.first_pfn + a.nr - 1) < a.first_pfn) ||
+ ((a.first_pfn + a.nr - 1) > domain_get_maximum_gpfn(d)) )
+goto out;
+
+if ( a.hvmmem_type >= ARRAY_SIZE(memtype) ||
+ unlikely(a.hvmmem_type == HVMMEM_unused) )
+goto out;
+
+while ( a.nr > start_iter )
+{
+unsigned long pfn = a.first_pfn + start_iter;
+p2m_type_t t;
+
+get_gfn_unshare(d, pfn, &t);
+if ( p2m_is_paging(t) )
+{
+put_gfn(d, pfn);
+p2m_mem_paging_populate(d, pfn);
+rc = -EAGAIN;
+goto out;
+}
+if ( p2m_is_shared(t) )
+{
+put_gfn(d, pfn);
+rc = -EAGAIN;
+goto out;
+}
+if ( !hvm_allow_p2m_type_change(t, memtype[a.hvmmem_type]) )
+{
+put_gfn(d, pfn);
+goto out;
+}
+
+rc = p2m_change_type_one(d, pfn, t, memtype[a.hvmmem_type]);
+put_gfn(d, pfn);
+
+if ( rc )
+goto out;
+
+/* Check for continuation if it's not
Re: [Xen-devel] [PATCH] xenalyze: fix a spurious newline
On Thu, May 19, 2016 at 10:07:44AM +0100, George Dunlap wrote:
> On 19/05/16 05:04, Dario Faggioli wrote:
> > in dump mode, when tracing context switches.
> >
> > Signed-off-by: Dario Faggioli
>
> Acked-by: George Dunlap
>
Ack and queued.
> > ---
> > Cc: George Dunlap
> > Cc: Ian Jackson
> > Cc: Wei Liu
> > ---
> > tools/xentrace/xenalyze.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
> > index b949986..01ead8b 100644
> > --- a/tools/xentrace/xenalyze.c
> > +++ b/tools/xentrace/xenalyze.c
> > @@ -7655,7 +7655,7 @@ void sched_process(struct pcpu_info *p)
> > printf(", was runnable for %u.%uus, ", r->rsince /
> > 1000,
> > r->rsince % 1000);
> > if ( r->slice > 0 )
> > -printf("next slice %u.%uus\n", r->slice / 1000,
> > +printf("next slice %u.%uus", r->slice / 1000,
> > r->slice % 1000);
> > printf("\n");
> > }
> >
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/arm: smpboot: drop unneeded code in start_secondary
CPU0 boots up secondary CPUs one by one. Before booting one secondary CPU, CPU0 will assign hwid to smp_up_cpu and flush cache. After the secondary CPU boots up, CPU0 will assign MPIDR_INVALID to smp_up_cpu and flush cache. There is no need for secondary CPUs to assign MPIDR_INVALID to smp_up_cpu. So, drop it. Signed-off-by: Peng Fan Cc: Julien Grall Cc: Stefano Stabellini --- xen/arch/arm/smpboot.c | 1 - 1 file changed, 1 deletion(-) diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index c5109bf..6b3c157 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -309,7 +309,6 @@ void start_secondary(unsigned long boot_phys_offset, smp_wmb(); /* Now report this CPU is up */ -smp_up_cpu = MPIDR_INVALID; cpumask_set_cpu(cpuid, &cpu_online_map); smp_wmb(); -- 2.6.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: sched: avoid races on time values read from NOW()
On 19/05/16 09:11, Dario Faggioli wrote:
> or (even in cases where there is no race, e.g., outside
> of Credit2) avoid using a time sample which may be rather
> old, and hence stale.
>
> In fact, we should only sample NOW() from _inside_
> the critical region within which the value we read is
> used. If we don't, in case we have to spin for a while
> before entering the region, when actually using it:
>
> 1) we will use something that, at the veryy least, is
> not really "now", because of the spinning,
>
> 2) if someone else sampled NOW() during a critical
> region protected by the lock we are spinning on,
> and if we compare the two samples when we get
> inside our region, our one will be 'earlier',
> even if we actually arrived later, which is a
> race.
>
> In Credit2, we see an instance of 2), in runq_tickle(),
> when it is called by csched2_context_saved() as it samples
> NOW() before acquiring the runq lock. This makes things
> look like the time went backwards, and it confuses the
> algorithm (there's even a d2printk() about it, which would
> trigger all the time, if enabled).
>
> In RTDS, something similar happens in repl_timer_handler(),
> and there's another instance in schedule() (in generic code),
> so fix these cases too.
>
> While there, improve csched2_vcpu_wake() and and rt_vcpu_wake()
> a little as well (removing a pointless initialization, and
> moving the sampling a bit closer to its use). These two hunks
> entail no further functional changes.
>
> Signed-off-by: Dario Faggioli
Reviewed-by: George Dunlap
I agree this is a fairly low-risk bugfix that should be considered for 4.7.
-George
> ---
> Cc: George Dunlap
> Cc: Meng Xu
> Cc: Wei Liu
> ---
> xen/common/sched_credit2.c |4 ++--
> xen/common/sched_rt.c |7 +--
> xen/common/schedule.c |4 +++-
> 3 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index f95e509..1933ff1 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -1028,7 +1028,7 @@ static void
> csched2_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
> {
> struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
> -s_time_t now = 0;
> +s_time_t now;
>
> /* Schedule lock should be held at this point. */
>
> @@ -1085,8 +1085,8 @@ static void
> csched2_context_saved(const struct scheduler *ops, struct vcpu *vc)
> {
> struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
> -s_time_t now = NOW();
> spinlock_t *lock = vcpu_schedule_lock_irq(vc);
> +s_time_t now = NOW();
>
> BUG_ON( !is_idle_vcpu(vc) && svc->rqd != RQD(ops, vc->processor));
>
> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index aa3ffd2..0946101 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -1198,7 +1198,7 @@ static void
> rt_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
> {
> struct rt_vcpu * const svc = rt_vcpu(vc);
> -s_time_t now = NOW();
> +s_time_t now;
> bool_t missed;
>
> BUG_ON( is_idle_vcpu(vc) );
> @@ -1225,6 +1225,7 @@ rt_vcpu_wake(const struct scheduler *ops, struct vcpu
> *vc)
> * If a deadline passed while svc was asleep/blocked, we need new
> * scheduling parameters (a new deadline and full budget).
> */
> +now = NOW();
>
> missed = ( now >= svc->cur_deadline );
> if ( missed )
> @@ -1394,7 +1395,7 @@ rt_dom_cntl(
> * from the replq and does the actual replenishment.
> */
> static void repl_timer_handler(void *data){
> -s_time_t now = NOW();
> +s_time_t now;
> struct scheduler *ops = data;
> struct rt_private *prv = rt_priv(ops);
> struct list_head *replq = rt_replq(ops);
> @@ -1406,6 +1407,8 @@ static void repl_timer_handler(void *data){
>
> spin_lock_irq(&prv->lock);
>
> +now = NOW();
> +
> /*
> * Do the replenishment and move replenished vcpus
> * to the temporary list to tickle.
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 80fea39..5e35310 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -1320,7 +1320,7 @@ static void vcpu_periodic_timer_work(struct vcpu *v)
> static void schedule(void)
> {
> struct vcpu *prev = current, *next = NULL;
> -s_time_t now = NOW();
> +s_time_t now;
> struct scheduler *sched;
> unsigned long*tasklet_work = &this_cpu(tasklet_work_to_do);
> bool_ttasklet_work_scheduled = 0;
> @@ -1355,6 +1355,8 @@ static void schedule(void)
>
> lock = pcpu_schedule_lock_irq(cpu);
>
> +now = NOW();
> +
> stop_timer(&sd->s_timer);
>
> /* get policy-specific decision on scheduling... */
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 02/18] kbdif: add raw events passing
>>> On 18.05.16 at 18:32, wrote:
> xenkbd_raw carries raw linux event structure -- type, code & value,
> which allows support of more devices (e.g. touchscreens).
The "raw Linux event structure" may change, so you can't defer to
it. All related definitions would need to be added here, namely ...
> @@ -68,6 +70,13 @@ struct xenkbd_position
> int32_t rel_z; /* relative Z motion (wheel) */
> };
>
> +struct xenkbd_raw {
> +uint8_t type;/* XENKBD_TYPE_RAW */
> +uint16_t input_type;
> +uint16_t code;
> +int32_t value;
> +};
... values to be contained in the three fields which don't have a
comment.
Furthermore it looks like it's the backend that would produce the
new type, and hence there would need to be a means for the
frontend to enable their producing (or else an unsuspecting
frontend might get confused). The way such negotiation works
(likely through xenbus) would need to be documented here, too.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 10/18] xen: arm: add batch support to the XENMEM_p2m_lookup operation
>>> On 18.05.16 at 18:32, wrote: First of all, the description is misleading: You don't add anything _to_ XENMEM_p2m_lookup, you simply add this new sub-op. And then, we've had requests to add something like this more than once, and so far they've always got rejected. See the removed XENMEM_translate_gpfn_list. Hence an empty description here is definitely insufficient, as you'll need to explain why _now_ all of the sudden this is needed. Perhaps it would have been a good idea if you had asked up front whether something like this can be re-added, or what alternatives there are without doing so. I'll therefore not comment on the actual patch, which also has issues (but which aren't worth addressing if the whole thing is going to get dropped). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0
>>> On 18.05.16 at 18:32, wrote:
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -27,6 +27,9 @@
> static unsigned int __initdata opt_dom0_max_vcpus;
> integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>
> +static u64 __initdata opt_dom0_rambase_pfn = 0;
> +integer_param("dom0_rambase_pfn", opt_dom0_rambase_pfn);
Any addition of a command line option needs to be accompanied by
an entry in the command line doc.
> @@ -248,6 +251,8 @@ static void allocate_memory_11(struct domain *d, struct
> kernel_info *kinfo)
> const unsigned int min_order = get_order_from_bytes(MB(4));
> struct page_info *pg;
> unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
> +u64 rambase_pfn = opt_dom0_rambase_pfn;
Use of __initdata in a non-__init function.
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -583,16 +583,17 @@ static void check_low_mem_virq(void)
> }
> }
>
> -/* Allocate 2^@order contiguous pages. */
> -static struct page_info *alloc_heap_pages(
> +/* Allocate 2^@order contiguous pages at given pfn. */
> +static struct page_info *alloc_heap_pages_pfn(
> unsigned int zone_lo, unsigned int zone_hi,
> unsigned int order, unsigned int memflags,
> -struct domain *d)
> +struct domain *d, xen_pfn_t pfn)
Altering generic allocation interfaces like this, for a boot time only
purpose, doesn't seem warranted. Please reconsider the entire
approach.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 15/18] arm: Add ability to relocate Xen in over 4GB space
>>> On 18.05.16 at 18:32, wrote: > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -64,6 +64,7 @@ CFLAGS-$(HAS_PCI) += -DHAS_PCI > CFLAGS-$(HAS_IOPORTS) += -DHAS_IOPORTS > CFLAGS-$(HAS_PDX) += -DHAS_PDX > CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER > +CFLAGS-$(ARM32_RELOCATE_OVER_4GB) += -DARM32_RELOCATE_OVER_4GB Things like this should be done via Kconfig nowadays. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.3-testing test] 94573: trouble: blocked/broken
flight 94573 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94573/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 3 host-install(3) broken REGR. vs. 80927 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927 build-i3863 host-install(3) broken REGR. vs. 80927 build-amd64 3 host-install(3) broken REGR. vs. 80927 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-pv 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-pv1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1 baseline version: qemuu10c1b763c26feb645627a1639e722515f3e1e876 Last test of basis80927 2016-02-06 13:30:02 Z 102 days Testing same since93977 2016-05-10 11:09:16 Z8 days 23 attempts People who touched revisions under test: Gerd Hoffmann Stefano Stabellini jobs: build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-credit2 blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-xl-multivcpublocked test-amd64-amd64-pairblo
Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus
Since, AFAIUI, you're interested in non-Linux guests' perspective, I'm
adding Roger (and avoiding trimming, for his benefit), who can tell us
what he thinks of this all, from the FreeBSD point of view.
On Thu, May 19, 2016 at 10:49 AM, Juergen Gross wrote:
> On 19/05/16 10:09, Andrew Cooper wrote:
>> On 19/05/2016 08:53, Juergen Gross wrote:
>>> A guest kernel can use the vcpu_op hypercall sub-op
>>> VCPUOP_register_runstate_memory_area to get a copy of the
>>> vcpu_runstate_info of a vcpu mapped into its memory. As this structure
>>> has no update indicator it is only save to be read by the vcpu it is
>>> containing the runstate information of.
>>>
>>> Being able to read the runstate info of another cpu is required e.g.
>>> by the Linux kernel to be able to calculate vruntime: see
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2016-05/msg01790.html
>>>
>>> I'd suggest to add an "update in progress" indicator in the highest
>>> bit of vcpu_runstate_info->state_entry_time as this structure element is
>>> already used to detect vcpu scheduling when vcpu_runstate_info is read
>>> by the owning vcpu.
>>>
>>> The question is how to enable setting this indicator, as the guest must
>>> be able to cope with it (I believe the Linux kernel would just run fine,
>>> but we can't be sure this is true for all guests).
>>>
>>> I see the following possible solutions:
>>>
>>> a) Introduce a new vcpu_op hypercall sub-op for mapping the
>>>vcpu_runstate_info with update indicator support (a guest supporting
>>>this would try the new sub-op first and could fall back to
>>>VCPUOP_register_runstate_memory_area in case of ENOSYS).
>>>
>>> b) Add a virtual MSR to switch on the feature (not being able to set the
>>>appropriate bit would indicate the feature not being available). This
>>>is the variant KVM is using. Does ARM have something like MSRs?
>>>
>>> c) Add another hypercall to switch on the feature (similar to
>>>XENVER_get_features we could have a XENVER_set_features).
>>>
>>> Any preferences?
>>
>> However, irrespective of how you signal the request for new behaviour,
>> you should see about using a lockless clock rather than a single bit, as
>> a single bit can't indicate the case where a complete update has
>> occurred between two samplings. This will probably require an extension
>> to the current implementation, at which point you might be able to add a
>> capability field as well.
>
> That's the reason I've chosen state_entry_time as the home for the new
> bit. state_entry_time is guaranteed to change between two updates. So
> the logic would look like the following:
>
> do {
> old_entry_time = READ_ONCE(r->state_entry_time);
> rmb();
> new_state = READ_ONCE(*r);
> rmb();
> } while (new_state.state_entry_time != old_entry_time ||
> (old_entry_time >> 63));
>
>> Alternatively, the easiest way will probably be to add a new VMASSIST,
>> which allows the guest to opt into the new behaviour.
>
> Aah, nice. Yes, this seems to be a sensible option.
>
FWIW, this looks a good approach to me as well.
Regards,
Dario
--
<> (Raistlin Majere)
---
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: smpboot: drop unneeded code in start_secondary
Hi Peng, On 19/05/16 10:22, Peng Fan wrote: CPU0 boots up secondary CPUs one by one. Before booting one secondary CPU, CPU0 will assign hwid to smp_up_cpu and flush cache. After the secondary CPU boots up, NIT: s/the/a/ CPU0 will assign MPIDR_INVALID to smp_up_cpu and flush cache. There is no need for secondary CPUs to assign MPIDR_INVALID to smp_up_cpu. So, drop it. Signed-off-by: Peng Fan Cc: Julien Grall Cc: Stefano Stabellini Reviewed-by: Julien Grall Regards, --- xen/arch/arm/smpboot.c | 1 - 1 file changed, 1 deletion(-) diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index c5109bf..6b3c157 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -309,7 +309,6 @@ void start_secondary(unsigned long boot_phys_offset, smp_wmb(); /* Now report this CPU is up */ -smp_up_cpu = MPIDR_INVALID; cpumask_set_cpu(cpuid, &cpu_online_map); smp_wmb(); -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus
On Thu, 19 May 2016, Juergen Gross wrote: > > Alternatively, the easiest way will probably be to add a new VMASSIST, > > which allows the guest to opt into the new behaviour. > > Aah, nice. Yes, this seems to be a sensible option. If you are referring to VM_ASSIST, it is only available on x86. I suggest we use a feature flag instead. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: smpboot: drop unneeded code in start_secondary
On Thu, 19 May 2016, Julien Grall wrote: > Hi Peng, > > On 19/05/16 10:22, Peng Fan wrote: > > CPU0 boots up secondary CPUs one by one. Before booting > > one secondary CPU, CPU0 will assign hwid to smp_up_cpu > > and flush cache. After the secondary CPU boots up, > > NIT: s/the/a/ > > > CPU0 will assign MPIDR_INVALID to smp_up_cpu and flush > > cache. > > > > There is no need for secondary CPUs to assign MPIDR_INVALID > > to smp_up_cpu. So, drop it. > > > > Signed-off-by: Peng Fan > > Cc: Julien Grall > > Cc: Stefano Stabellini > > Reviewed-by: Julien Grall This is a cleanup, no need to commit it now. I'll add it to the 4.8 branch. > > > --- > > xen/arch/arm/smpboot.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c > > index c5109bf..6b3c157 100644 > > --- a/xen/arch/arm/smpboot.c > > +++ b/xen/arch/arm/smpboot.c > > @@ -309,7 +309,6 @@ void start_secondary(unsigned long boot_phys_offset, > > smp_wmb(); > > > > /* Now report this CPU is up */ > > -smp_up_cpu = MPIDR_INVALID; > > cpumask_set_cpu(cpuid, &cpu_online_map); > > smp_wmb(); > > > > > > -- > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus
>>> On 19.05.16 at 12:40, wrote: > On Thu, 19 May 2016, Juergen Gross wrote: >> > Alternatively, the easiest way will probably be to add a new VMASSIST, >> > which allows the guest to opt into the new behaviour. >> >> Aah, nice. Yes, this seems to be a sensible option. > > If you are referring to VM_ASSIST, it is only available on x86. I > suggest we use a feature flag instead. A feature flag can only be checked by the guest, not set. How about enabling VMASSIST for ARM? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus
On Thu, 19 May 2016, Jan Beulich wrote: > >>> On 19.05.16 at 12:40, wrote: > > On Thu, 19 May 2016, Juergen Gross wrote: > >> > Alternatively, the easiest way will probably be to add a new VMASSIST, > >> > which allows the guest to opt into the new behaviour. > >> > >> Aah, nice. Yes, this seems to be a sensible option. > > > > If you are referring to VM_ASSIST, it is only available on x86. I > > suggest we use a feature flag instead. > > A feature flag can only be checked by the guest, not set. How > about enabling VMASSIST for ARM? Sure ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86, locking: Remove ticket (spin)lock implementation
On 18/05/2016 21:34, Peter Zijlstra wrote: >> I don't know of any enterprise distro that is shipping anything >> > more modern than 4.1? > RHEL 7-- v3.10 > SLES 12 -- v3.12 > Debian Jessie -- v3.16 > Ubuntu 16.04 LTS -- v4.4 > > But waiting for the major enterprise distros (RHEL/SLES) would mean > another decade or so before people start using it. We don't usually wait > this long for anything. We're looking at converting a few specific spinlocks to qspinlock in RHEL, though we cannot convert all of them due to the spin_lock_t ABI. It won't get into customer's hands for a while of course. Thanks, Paolo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Embedded-pv-devel] [PATCH RFC 00/18] System adjustment to customer needs.
Hello, On 18/05/16 20:17, Meng Xu wrote: On Wed, May 18, 2016 at 12:32 PM, Andrii Anisov wrote: This series RFC patches from the currently ongoing production project. This patch series presents changes needed to fit the system into customer requirements as well as workaround limitations of the Jacinto6 SoC. IMHO, it will be better, if possible, to describe the exact customer requirements this patch series tries to satisfy. I'm curious at what the requirements are and if the requirements are general enough for many other customers. :-) I agree with Meng here. We need to understand the use case and see if it is possible to generalize it for everyone. I looked quickly at this patch series and noticed that most of patches miss details on why it is necessary and what you are trying solve. Can you give us more details? Similarly, what are the limitations for the Jacinto6 SoC that need to be workaround? If the board is not supported by Xen, can we say Xen will support the board with the warkaround? Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: sched: avoid races on time values read from NOW()
On Thu, May 19, 2016 at 10:11:35AM +0200, Dario Faggioli wrote: > or (even in cases where there is no race, e.g., outside > of Credit2) avoid using a time sample which may be rather > old, and hence stale. > > In fact, we should only sample NOW() from _inside_ > the critical region within which the value we read is > used. If we don't, in case we have to spin for a while > before entering the region, when actually using it: > > 1) we will use something that, at the veryy least, is > not really "now", because of the spinning, > > 2) if someone else sampled NOW() during a critical > region protected by the lock we are spinning on, > and if we compare the two samples when we get > inside our region, our one will be 'earlier', > even if we actually arrived later, which is a > race. > > In Credit2, we see an instance of 2), in runq_tickle(), > when it is called by csched2_context_saved() as it samples > NOW() before acquiring the runq lock. This makes things > look like the time went backwards, and it confuses the > algorithm (there's even a d2printk() about it, which would > trigger all the time, if enabled). > > In RTDS, something similar happens in repl_timer_handler(), > and there's another instance in schedule() (in generic code), > so fix these cases too. > > While there, improve csched2_vcpu_wake() and and rt_vcpu_wake() > a little as well (removing a pointless initialization, and > moving the sampling a bit closer to its use). These two hunks > entail no further functional changes. > > Signed-off-by: Dario Faggioli > --- > Cc: George Dunlap > Cc: Meng Xu > Cc: Wei Liu Subject to review from Meng and George: Release-acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 03/18] xen/arm: allow to allocate 1/128/256/512 Mb memory chunks
Hello, On 18/05/16 17:32, Andrii Anisov wrote: From: Andrii Tseglytskyi This is done to allow possibility of having 1 to 1 memory mapping chunks with size 1/128/256/512 Mb what can sagnificantly decrease time of memory significantly allocation and fragmentation for 1-to-1 mapped domains. I cannot find any patch in this series to add support for direct memory mapped guest. Can you give details on why this patch would be an improvement for any guest and how you choose the new allocations size? Regards, Signed-off-by: Andrii Tseglytskyi Signed-off-by: Iurii Konovalenko --- tools/libxc/xc_dom_arm.c | 24 1 file changed, 24 insertions(+) diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index aeaba54..5ee8eef 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -33,7 +33,11 @@ #define LPAE_SHIFT 9 #define PFN_4K_SHIFT (0) +#define PFN_1M_SHIFT (PFN_4K_SHIFT + 8) #define PFN_2M_SHIFT (PFN_4K_SHIFT+LPAE_SHIFT) +#define PFN_128M_SHIFT (PFN_2M_SHIFT + 6) +#define PFN_256M_SHIFT (PFN_128M_SHIFT + 1) +#define PFN_512M_SHIFT (PFN_256M_SHIFT + 1) #define PFN_1G_SHIFT (PFN_2M_SHIFT+LPAE_SHIFT) #define PFN_512G_SHIFT (PFN_1G_SHIFT+LPAE_SHIFT) @@ -359,11 +363,31 @@ static int populate_guest_memory(struct xc_dom_image *dom, if ( rc < 0 ) break; if ( rc > 0 ) continue; +rc = populate_one_size(dom, PFN_512M_SHIFT, + base_pfn + pfn, &allocsz, extents); +if ( rc < 0 ) break; +if ( rc > 0 ) continue; + +rc = populate_one_size(dom, PFN_256M_SHIFT, + base_pfn + pfn, &allocsz, extents); +if ( rc < 0 ) break; +if ( rc > 0 ) continue; + +rc = populate_one_size(dom, PFN_128M_SHIFT, + base_pfn + pfn, &allocsz, extents); +if ( rc < 0 ) break; +if ( rc > 0 ) continue; + rc = populate_one_size(dom, PFN_2M_SHIFT, base_pfn + pfn, &allocsz, extents); if ( rc < 0 ) break; if ( rc > 0 ) continue; +rc = populate_one_size(dom, PFN_1M_SHIFT, + base_pfn + pfn, &allocsz, extents); +if ( rc < 0 ) break; +if ( rc > 0 ) continue; + rc = populate_one_size(dom, PFN_4K_SHIFT, base_pfn + pfn, &allocsz, extents); if ( rc < 0 ) break; -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation
On May 19, 2016 2:13 PM, Jan Beulich wrote: > >>> "Xu, Quan" 05/19/16 3:35 AM >>> > >On May 19, 2016 8:33 AM, Tian, Kevin wrote: > >> A single default value for both IOMMU-side and device-side is anyway > >> not optimal. What about introducing a new knob e.g. > >> vtd_qi_device_timeout specifically for device-side flush while using > >> vtd_qi_timeout for other places? If device-side timeout is not specified, > >> it is > then default to vtd_qi_timeout. > > There should imo be a single command line option, allowing for two values to > be passed (e.g. comma-separated). > As mentioned, 1 ms is enough for VT-d IOTLB/Context/IEC invalidation, so we are no need to increasing the value of timeout or introduce a boot-time changed parameter. What about a constant (e.g. a macro), 1 ms, for VT-d IOTLB/Context/IEC invalidation timeout. For Device-TLB invalidation, we can introduce 'vtd_qi_device_timeout', which is boot-time changed, and 1 ms by default. Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 08/18] tools/misc: Set timeout value from watchdog daemon
On Wed, May 18, 2016 at 07:32:31PM +0300, Andrii Anisov wrote: > From: Viktor Kleinik > > Signed-off-by: Viktor Kleinik I have a feeling this can probably be squashed into previous patch. But please don't squash this yet, let's start with better commit message. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 07/18] tools/misc: Modify Xen watchdog daemon
On Wed, May 18, 2016 at 07:32:30PM +0300, Andrii Anisov wrote: > From: Viktor Kleinik > > This change allows watchdog daemon to work thru watchdog device > on the file system. > > Signed-off-by: Viktor Kleinik The commit message is not clear enough as to why you want to delete a bunch of code. I'm afraid I'm not able to review a patch like this. Doesn't this patch break existing behaviour? Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 04/18] libxl: add ability to set rambase_pfn via cfg file
On Wed, May 18, 2016 at 07:32:27PM +0300, Andrii Anisov wrote:
> From: Oleksandr Tyshchenko
>
> In case of missing required property in cfg file
> the default value (0x4) should be used.
Assuming this is absolutely needed (whether it is the case I don't
know, I will leave that to ARM maintainers)...
>
> Signed-off-by: Oleksandr Tyshchenko
> Signed-off-by: Iurii Konovalenko
> Signed-off-by: Iurii Mykhalskyi
[...]
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 1699f32..5b0b50a 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -100,6 +100,7 @@
> #define LIBXL_HVM_EXTRA_MEMORY 2048
> #define LIBXL_MIN_DOM0_MEM (128*1024)
> #define LIBXL_INVALID_GFN (~(uint64_t)0)
> +#define LIBXL_INVALID_RAM_BASE (~(uint64_t)0)
> /* use 0 as the domid of the toolstack domain for now */
> #define LIBXL_TOOLSTACK_DOMID 0
> #define QEMU_SIGNATURE "DeviceModelRecord0002"
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 502a148..b6cc8d2 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -416,6 +416,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
> ("target_memkb",MemKB),
> ("video_memkb", MemKB),
> ("shadow_memkb",MemKB),
> +("rambase", uint64, {'init_val': 'LIBXL_INVALID_RAM_BASE'}),
Please make this ARM specific.
You would also need to provide a LIBXL_HAVE macro in libxl.h. See
various examples there.
> ("rtc_timeoffset", uint32),
> ("exec_ssidref",uint32),
> ("exec_ssid_label", string),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 9a2870e..28d57c3 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -31,6 +31,7 @@
> #include
> #include /* for utsname in xl info */
> #include
> +#include
I don't think you need this. In fact, please don't do this. :-)
> #include
> #include
> #include
> @@ -1352,6 +1353,18 @@ static void parse_config_data(const char
> *config_source,
> if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
> b_info->max_memkb = l * 1024;
>
> +#ifdef GUEST_RAM_BASE
> +if (!xlu_cfg_get_long (config, "rambase_pfn", &l, 0)) {
> +/* TODO add more detailed check for valid value */
> +uint64_t rambase = (uint64_t)l << XC_PAGE_SHIFT;
> +if (rambase > (GUEST_RAM0_BASE + GUEST_RAM0_SIZE)) {
> +fprintf(stderr, "ERROR: invalid value 0x%lx for
> \"rambase_pfn\"\n", l);
> +exit (1);
> +}
> +b_info->rambase = rambase;
> +}
> +#endif
> +
> if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
> vcpus = l;
> if (libxl_cpu_bitmap_alloc(ctx, &b_info->avail_vcpus, l)) {
> --
> 2.8.2
>
>
> ___
> 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 RFC 06/18] libxl: parse config data during domain reboot
On Wed, May 18, 2016 at 07:32:29PM +0300, Andrii Anisov wrote:
> From: Viktor Kleinik
>
> We need to parse config data during domain reboot
> to get correct I/O memory regions for mapping.
>
> Signed-off-by: Viktor Kleinik
> ---
> tools/libxl/xl_cmdimpl.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 28d57c3..98a46bc 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2988,6 +2988,21 @@ start:
> d_config.c_info.name = strdup(common_domname);
> }
>
> + if (config_file) {
> + libxl_domain_config_init(&d_config);
> +
> + ret = libxl_read_file_contents(ctx, config_file,
> +&config_data, &config_len);
> + if (ret) {
> + LOG("Failed to read config file: %s: %s\n",
> + config_file, strerror(errno));
> + goto out;
> + }
> +
> + parse_config_data(config_file, config_data, config_len,
> + &d_config);
> + }
> +
I think libxl has already preserve the configuration for you?
This will break device hotplug I think.
Wei.
> /*
> * XXX FIXME: If this sleep is not there then domain
> * re-creation fails sometimes.
> --
> 2.8.2
>
>
> ___
> 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 RFC 09/18] tools: Allow to cross-compile xentop
On Wed, May 18, 2016 at 07:32:32PM +0300, Andrii Anisov wrote: > From: Oleksandr Dmytryshyn > > Signed-off-by: Oleksandr Dmytryshyn > Signed-off-by: Iurii Konovalenko > --- > tools/xenstat/Makefile | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/tools/xenstat/Makefile b/tools/xenstat/Makefile > index 901be4a..440b1b7 100644 > --- a/tools/xenstat/Makefile > +++ b/tools/xenstat/Makefile > @@ -4,12 +4,10 @@ include $(XEN_ROOT)/tools/Rules.mk > SUBDIRS := > SUBDIRS += libxenstat > > -# This doesn't cross-compile (cross-compile environments rarely have curses) > -ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH)) > +# This compiles if compiler environment has curses You should have a option that is set by configure to guard this. Wei. > ifeq ($(wildcard /usr/include/curses.h),/usr/include/curses.h) > SUBDIRS += xentop > endif > -endif > > .PHONY: all install clean distclean > > -- > 2.8.2 > > > ___ > 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 RFC 01/18] xen/tools: Fix virtual disks helper scripts.
On Wed, May 18, 2016 at 07:32:24PM +0300, Andrii Anisov wrote:
> This patch makes virtual disks helper scripts be functional
> in busybox environment. Actually we call sh insteand of bash and
> rewrite loop with counter to be properly parsed by ash.
>
> Signed-off-by: Andrii Anisov
> Signed-off-by: Andrii Tseglytskyi
> ---
> tools/hotplug/Linux/block| 2 +-
> tools/hotplug/Linux/locking.sh | 9 +++--
> tools/hotplug/Linux/xen-hotplug-common.sh.in | 2 +-
> 3 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/tools/hotplug/Linux/block b/tools/hotplug/Linux/block
> index 8d2ee9d..6a725db 100644
> --- a/tools/hotplug/Linux/block
> +++ b/tools/hotplug/Linux/block
> @@ -1,4 +1,4 @@
> -#!/bin/bash
> +#!/bin/sh
>
> dir=$(dirname "$0")
> . "$dir/block-common.sh"
> diff --git a/tools/hotplug/Linux/locking.sh b/tools/hotplug/Linux/locking.sh
> index c6a7e96..b8e9515 100644
> --- a/tools/hotplug/Linux/locking.sh
> +++ b/tools/hotplug/Linux/locking.sh
> @@ -23,9 +23,14 @@ LOCK_BASEDIR=/var/run/xen-hotplug
>
> _setlockfd()
> {
> +local lock_
> local i
> -for ((i = 0; i < ${#_lockdict}; i++))
> -do [ -z "${_lockdict[$i]}" -o "${_lockdict[$i]}" = "$1" ] && break
> +let i=0
> +
> +for lock_ in _lockdict ;
> +do
> +[ -z "$lock_" -o "$lock_" = "$1" ] && break
> +(( i++ ))
> done
> _lockdict[$i]="$1"
> let _lockfd=200+i
> diff --git a/tools/hotplug/Linux/xen-hotplug-common.sh.in
> b/tools/hotplug/Linux/xen-hotplug-common.sh.in
> index d5d0b69..42e46e3 100644
> --- a/tools/hotplug/Linux/xen-hotplug-common.sh.in
> +++ b/tools/hotplug/Linux/xen-hotplug-common.sh.in
> @@ -51,7 +51,7 @@ sigerr() {
>fatal "$0 failed; error detected."
> }
>
> -trap sigerr ERR
> +#trap sigerr ERR
I know why you want to comment this out but you basically break the
error handling protocol. See the fatal function at the beginning of this
file.
So we can't take this patch. And you should probably fix your own
environment, too.
Wei.
>
>
> ##
> --
> 2.8.2
>
>
> ___
> 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 RFC 12/18] libxl: Fix unneeded domain reboot during destroy routine
On Wed, May 18, 2016 at 07:32:35PM +0300, Andrii Anisov wrote:
> From: Viktor Kleinik
>
> During domain destroy we should change its state from "alive"
> to "dying" to prevent reboot because of watchdog timeout.
>
> Signed-off-by: Viktor Kleinik
> ---
> tools/libxl/libxl.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 1366177..ac50bda 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1634,6 +1634,10 @@ void libxl__destroy_domid(libxl__egc *egc,
> libxl__destroy_domid_state *dis)
> dis->drs.callback = devices_destroy_cb;
> dis->drs.force = 1;
> libxl__devices_destroy(egc, &dis->drs);
> +rc = xc_domain_destroy(ctx->xch, domid);
> +if (rc < 0) {
> +LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_destroy
> failed for %d", domid);
> +}
What is the code path here? Have you checked the other place which calls
xc_domain_destroy? Now there are two calls to xc_domain_destroy, which
doesn't seem right to me.
Wei.
> return;
>
> out:
> --
> 2.8.2
>
>
> ___
> 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 RFC 17/18] tools: Introduce ARM32_SEPAR_MEM_SPLIT option
On Wed, May 18, 2016 at 07:32:40PM +0300, Andrii Anisov wrote: > From: Iurii Mykhalskyi > > This option enables separate memory allocation in > low & over 4GB address space. > With this option enabled in domain config files > "memory" parameter are used to specify domain low memory > "memory_high" - to specify over 4GB allocated memory > > If you didn't specify high memory with this option enabled, > domain memory will be limited to 4GB (zone 20) > I don't think such option is future proof enough -- what if you suddenly want several memory regions? I haven't actually looked at the code, merely asking some (perhaps dumb) questions first. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation
>>> On 19.05.16 at 13:26, wrote: > On May 19, 2016 2:13 PM, Jan Beulich wrote: >> >>> "Xu, Quan" 05/19/16 3:35 AM >>> >> >On May 19, 2016 8:33 AM, Tian, Kevin wrote: >> >> A single default value for both IOMMU-side and device-side is anyway >> >> not optimal. What about introducing a new knob e.g. >> >> vtd_qi_device_timeout specifically for device-side flush while using >> >> vtd_qi_timeout for other places? If device-side timeout is not specified, >> >> it is >> then default to vtd_qi_timeout. >> >> There should imo be a single command line option, allowing for two values to >> be passed (e.g. comma-separated). > > As mentioned, 1 ms is enough for VT-d IOTLB/Context/IEC invalidation, so we > are no need to increasing the value of timeout or introduce a boot-time > changed parameter. > What about a constant (e.g. a macro), 1 ms, for VT-d IOTLB/Context/IEC > invalidation timeout. If you're absolutely certain no-one will ever find a need to increase that value - sure. > For Device-TLB invalidation, we can introduce 'vtd_qi_device_timeout', which > is boot-time changed, and 1 ms by default. One question is whether making this a VT-d specific command line option is a good idea: Other IOMMU implementations ought to be in need of doing device IOTLB invalidation too, at least sooner or later. The other question is whether any timeout lower than the current one can be considered safe (and hence is usable as a default). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 04/18] libxl: add ability to set rambase_pfn via cfg file
Hello,
On 18/05/16 17:32, Andrii Anisov wrote:
From: Oleksandr Tyshchenko
In case of missing required property in cfg file
the default value (0x4) should be used.
The memory layout for the guest is static and may change between
version. By allowing the user to specify the base of the RAM, you expose
the Xen internal. The user cannot use this option without knowing the
version of Xen 4.4 and looking at xen/include/public/arch-arm.h.
Also, you need to explain why a user would want to change the
rambase_pfn. I suspect it is for supporting direct mapped domain. If so,
I think the way forward is to expose the same memory layout as the
hardware rather than trying to make the layout half-static/dynamic.
Exposing the same layout as the hardware would allow you to map the
device MMIOs 1:1 and avoid unnecessary IPA -> PA translation via an
hypercall (see patch #10).
Lastly, the commit message should explain the restriction. For instance,
I would have expect to be able to specify any value. However based on
the check in xl, this is not possible.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
---
tools/libxc/xc_dom_arm.c | 13 +++--
tools/libxl/libxl_arm.c | 10 --
tools/libxl/libxl_create.c | 5 +
tools/libxl/libxl_dom.c | 6 +++---
tools/libxl/libxl_internal.h | 1 +
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 13 +
7 files changed, 38 insertions(+), 11 deletions(-)libxc
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 5ee8eef..96df669 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -415,9 +415,12 @@ int arch_setup_meminit(struct xc_dom_image *dom)
uint64_t modbase;
uint64_t ramsize = (uint64_t)dom->total_pages << XC_PAGE_SHIFT;
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+uint64_t guest_ramsize = (GUEST_RAM0_BASE + GUEST_RAM0_SIZE) -
+ guest_rambase;
-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
-const uint64_t bankmax[] = GUEST_RAM_BANK_SIZES;
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};
+const uint64_t bankmax[] = {guest_ramsize, GUEST_RAM1_SIZE};
/* Convenient */
const uint64_t kernbase = dom->kernel_seg.vstart;
@@ -433,8 +436,6 @@ int arch_setup_meminit(struct xc_dom_image *dom)
xen_pfn_t p2m_size;
uint64_t bank0end;
-assert(dom->rambase_pfn << XC_PAGE_SHIFT == bankbase[0]);
-
if ( modsize + kernsize > bankmax[0] )
{
DOMPRINTF("%s: Not enough memory for the kernel+dtb+initrd",
@@ -448,11 +449,11 @@ int arch_setup_meminit(struct xc_dom_image *dom)
return -1;
}
-if ( ramsize > GUEST_RAM_MAX )
+if ( ramsize > (bankmax[0] + bankmax[1]) )
{
DOMPRINTF("%s: ram size is too large for guest address space: "
"%"PRIx64" > %llx",
- __FUNCTION__, ramsize, GUEST_RAM_MAX);
+ __FUNCTION__, ramsize, bankmax[0] + bankmax[1]);
return -1;
}
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 0af8010..7f9547b 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -372,7 +372,10 @@ static int make_memory_nodes(libxl__gc *gc, void *fdt,
{
int res, i;
const char *name;
-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};
for (i = 0; i < GUEST_RAM_BANKS; i++) {
name = GCSPRINTF("memory@%"PRIx64, bankbase[i]);
@@ -914,7 +917,10 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc
*gc,
{
void *fdt = dom->devicetree_blob;
int i;
-const uint64_t bankbase[] = GUEST_RAM_BANK_BASES;
+
+uint64_t guest_rambase = (uint64_t)dom->rambase_pfn << XC_PAGE_SHIFT;
+
+const uint64_t bankbase[] = {guest_rambase, GUEST_RAM1_BASE};
const struct xc_dom_seg *ramdisk = dom->ramdisk_blob ?
&dom->ramdisk_seg : NULL;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 350e274..1c0579c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -182,6 +182,11 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
if (b_info->target_memkb == LIBXL_MEMKB_DEFAULT)
b_info->target_memkb = b_info->max_memkb;
+#ifdef GUEST_RAM_BASE
+if (b_info->rambase == LIBXL_INVALID_RAM_BASE)
+b_info->rambase = GUEST_RAM0_BASE;
xl is not the only front-end for libxl. So you need to validate the
value of rambase here.
+#endif
+
libxl_defbool_setdefault(&b_info->claim_mode, false);
libxl_defbool_setdefault(&b_info->localtime, false);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2da3ac4..be6598f 100644
--- a/tools/libxl/libxl_do
Re: [Xen-devel] Resend: [PATCH] v3 - Add exclusive locking option to block-iscsi
On Thu, May 19, 2016 at 11:29:32AM +1000, Steven Haigh wrote:
> On 2016-05-09 14:22, Steven Haigh wrote:
> >On 2016-05-05 15:52, Steven Haigh wrote:
> >>On 2016-05-05 12:32, Steven Haigh wrote:
> >>>Overview
> >>>
> >>>If you're using iSCSI, you can mount a target by multiple Dom0
> >>>machines on the same target. For non-cluster aware filesystems, this
> >>>can lead to disk corruption and general bad times by all. The iSCSI
> >>>protocol allows the use of persistent reservations as per the SCSI
> >>>disk spec. Low level SCSI commands for locking are handled by the
> >>>sg_persist program (bundled with sg3_utils package in EL).
> >>>
> >>>The aim of this patch is to create a 'locktarget=y' option specified
> >>>within the disk 'target' command for iSCSI to lock the target in
> >>>exclusive mode on VM start with a key generated from the local systems
> >>>IP, and release this lock on the shutdown of the DomU.
> >>>
> >>>Example Config:
> >>>disk=
> >>>['script=block-iscsi,vdev=xvda,target=iqn=iqn.1986-03.com.sun:02:mytarget,portal=iscsi.example.com,locktarget=y']
> >>>
> >>>In writing this, I have also re-factored parts of the script to put
> >>>some things in what I believe to be a better place to make expansion
> >>>easier. This is mainly in removing functions that purely call other
> >>>functions with no actual code execution.
> >>>
> >>>Signed-off-by: Steven Haigh
> >>>
> >>>(on a side note, first time I've submitted a patch to the list and I'm
> >>>currently stuck on a webmail client, so apologies in advance if this
> >>>all goes wrong ;)
> >>
> >>Changes in v2:
> >>Bugfix: Call find_device to locate the /dev/sdX component of the iSCSI
> >>target before trying to run unlock_device().
> >>
> >>Apologies for this oversight.
> >>
> >
> >Changes in v3:
> >* Split the block-iscsi cleanup into a seperate patch
> >(block-iscsi-locking-v3_01_simplify_block-iscsi.patch).
> >* Add locking in second patch file
> >(block-iscsi-locking-v3_02_add_locking.patch)
>
> Resend of patches.
>
> There was a mention of having to add further documentation to
> xl-disk-configuration.txt - however there are no mentions of block-iscsi
> script within the documentation to add. As such, it probably would be out of
> place to add things here.
>
> The locktarget option is presented directly to the block-iscsi script and
> not evaluated anywhere outside this script.
>
Sorry I dropped the ball. I think it would be helpful if you or Roger
can send a patch to document all the knobs for block-iscsi. It doesn't
have to be in that file, we can figure out where to add.
FYI we are in the process of making 4.7 release, so the response here
might take a bit longer. FAOD this patch is not targeting 4.7, right?
I'm not too familiar with block script so I think I will
defer this to Roger. I've also CC'ed Ian for you.
To make a proper patch, please could you read:
http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
Wei.
> --
> Steven Haigh
>
> Email: net...@crc.id.au
> Web: https://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> --- block-iscsi.orig2016-05-09 15:12:02.489495212 +1000
> +++ block-iscsi 2016-05-09 15:16:35.447480532 +1000
> @@ -31,16 +31,6 @@
> echo $1 | sed "s/^\("$2"\)//"
> }
>
> -check_tools()
> -{
> -if ! command -v iscsiadm > /dev/null 2>&1; then
> -fatal "Unable to find iscsiadm tool"
> -fi
> -if [ "$multipath" = "y" ] && ! command -v multipath > /dev/null 2>&1;
> then
> -fatal "Unable to find multipath"
> -fi
> -}
> -
> # Sets the following global variables based on the params field passed in as
> # a parameter: iqn, portal, auth_method, user, multipath, password
> parse_target()
> @@ -52,12 +42,18 @@
> case $param in
> iqn=*)
> iqn=$(remove_label $param "iqn=")
> +if ! command -v iscsiadm > /dev/null 2>&1; then
> +fatal "Could not find iscsiadm tool."
> +fi
> ;;
> portal=*)
> portal=$(remove_label $param "portal=")
> ;;
> multipath=*)
> multipath=$(remove_label $param "multipath=")
> +if ! command -v multipath > /dev/null 2>&1; then
> +fatal "Multipath selected, but no multipath tools found"
> +fi
> ;;
> esac
> done
> @@ -96,40 +92,6 @@
> fi
> }
>
> -# Attaches the target $iqn in $portal and sets $dev to point to the
> -# multipath device
> -attach()
> -{
> -do_or_die iscsiadm -m node --targetname "$iqn" -p "$portal" --login >
> /dev/null
> -find_device
> -}
> -
> -# Discovers targets in $portal and checks that $iqn is one of those targets
> -# Also sets the auth parameters to attach the device
> -prepare()
> -{
> -# Check if target is already opened
> -iscsiadm -m session 2>&1 | grep -q "$iqn" && fatal "Device already
> opened"
> -# Discover portal targets
> -iscsiadm -m discovery -t st -p $por
Re: [Xen-devel] [PATCH RFC 05/18] xen/arm: allow reassigning of hw interrupts to guest domain
Hello,
On 18/05/16 17:32, Andrii Anisov wrote:
From: Andrii Tseglytskyi
Patch allows reassigning of hardware interrupts from dom0 to
other guest domain.
Can you explain why route_irq_to_guest should be able to cope with
reassigning an IRQ rather than having dom0 calling
XEN_DOMCTL_unbind_pt_irq beforehand?
Also, this patch does more than allowing an IRQ to be reassigned from
DOM0 to DOMU, it also allows DOMU to DOMU.
Regards,
Signed-off-by: Andrii Tseglytskyi
Signed-off-by: Iurii Konovalenko
---
xen/arch/arm/irq.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 1f38605..c470613 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -481,12 +481,23 @@ int route_irq_to_guest(struct domain *d, unsigned int
virq,
}
if ( test_bit(_IRQ_GUEST, &desc->status) )
-printk(XENLOG_G_ERR "IRQ %u is already used by domain %u\n",
- irq, ad->domain_id);
+{
+printk(XENLOG_G_DEBUG "IRQ %u is reassigned from domain %u to domain
%u\n",
+irq, ad->domain_id, d->domain_id);
+
+retval = gic_remove_irq_from_guest(ad, irq, desc);
+if ( retval )
+printk(XENLOG_G_ERR "failed to remove IRQ %u from domain %u
(%d)\n",
+irq, ad->domain_id, retval);
+xfree(desc->action);
+desc->action = NULL;
+}
else
+{
printk(XENLOG_G_ERR "IRQ %u is already used by Xen\n", irq);
-retval = -EBUSY;
-goto out;
+ retval = -EBUSY;
+ goto out;
+}
}
retval = __setup_irq(desc, 0, action);
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0
Hi Jan,
On 19/05/16 10:41, Jan Beulich wrote:
On 18.05.16 at 18:32, wrote:
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -27,6 +27,9 @@
static unsigned int __initdata opt_dom0_max_vcpus;
integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+static u64 __initdata opt_dom0_rambase_pfn = 0;
+integer_param("dom0_rambase_pfn", opt_dom0_rambase_pfn);
Any addition of a command line option needs to be accompanied by
an entry in the command line doc.
@@ -248,6 +251,8 @@ static void allocate_memory_11(struct domain *d, struct
kernel_info *kinfo)
const unsigned int min_order = get_order_from_bytes(MB(4));
struct page_info *pg;
unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
+u64 rambase_pfn = opt_dom0_rambase_pfn;
Use of __initdata in a non-__init function.
All the functions within domain_build.c should have the attributes
__init. However, it has been forgotten for half of them.
I am planning to send a patch to enforce it using the Makefile rules.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing baseline-only test] 44431: trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 44431 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44431/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm 4 capture-logs !broken [st=!broken!] build-armhf 4 capture-logs !broken [st=!broken!] build-armhf-pvops 4 capture-logs !broken [st=!broken!] build-armhf-xsm 3 host-install(3) broken REGR. vs. 44401 build-armhf 3 host-install(3) broken REGR. vs. 44401 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44401 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 44401 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 44401 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44401 test-amd64-amd64-xl-qemut-winxpsp3 9 windows-install fail like 44401 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-xl-midway1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: xen aa3cdb6cb666400768950503863b7c3cf508f581 baseline version: xen 39546d1360d954c2d0e2ff71dc74851e7081f61f Last test of basis44401 2016-05-10 17:29:14 Z8 days Testing same since44431 2016-05-19 05:19:33 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Ian Campbell Ian Jackson Jan Beulich Julien Grall Kyle J. Temkin Kyle Temkin Shanker Donthineni Stefano Stabellini Stefano Stabellini Vikram Sethi Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm broken build-i386-xsm pass build-amd64 pass build-armhf broken build-i386 pass build-amd64-libvirt pass build-armhf-libvirt blocked build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopsbroken build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl blocked test-amd64-i386-xl pass test-amd64-amd64-xl-qem
[Xen-devel] [ovmf baseline-only test] 44433: all pass
This run is configured for baseline tests only. flight 44433 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44433/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf 81c1460695f783a3f91431b2babea623556a7f5d baseline version: ovmf 720eea6aa80b48acb05c1adc0f835e849d71da97 Last test of basis44430 2016-05-18 20:20:23 Z0 days Testing same since44433 2016-05-19 06:55:07 Z0 days1 attempts People who touched revisions under test: Dandan Bi Ma, Maurice Maurice Ma jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 81c1460695f783a3f91431b2babea623556a7f5d Author: Dandan Bi Date: Tue May 17 11:25:34 2016 +0800 MdeModulePkg/UiApp: Exit function when parameter is unsupported or invalid When the parameter is unsupported or invalid, should exit the function. Cc: Qiu Shumin Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi Reviewed-by: Eric Dong Reviewed-by: Qiu Shumin commit c28306c3d6e0c7721abc937d8f47c3f1ccecf323 Author: Ma, Maurice Date: Tue May 17 05:26:06 2016 +0800 MdeModulePkg: Skip invalid bus number scanning in PciBusDxe driver When PcdPciDisableBusEnumeration is enabled, the PciBus driver might get into a dead loop if the secondary bus register on PCI bridge is not programmed or programmed improperly. Adding this check to avoid any potential dead loop caused by this. Cc: Feng Tian Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Maurice Ma Reviewed-by: Ruiyu Ni Reviewed-by: Lee Leahy ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0
>>> On 19.05.16 at 14:26, wrote:
> On 19/05/16 10:41, Jan Beulich wrote:
> On 18.05.16 at 18:32, wrote:
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -27,6 +27,9 @@
>>> static unsigned int __initdata opt_dom0_max_vcpus;
>>> integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>>>
>>> +static u64 __initdata opt_dom0_rambase_pfn = 0;
>>> +integer_param("dom0_rambase_pfn", opt_dom0_rambase_pfn);
>>
>> Any addition of a command line option needs to be accompanied by
>> an entry in the command line doc.
>>
>>> @@ -248,6 +251,8 @@ static void allocate_memory_11(struct domain *d, struct
>>> kernel_info *kinfo)
>>> const unsigned int min_order = get_order_from_bytes(MB(4));
>>> struct page_info *pg;
>>> unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
>>> +u64 rambase_pfn = opt_dom0_rambase_pfn;
>>
>> Use of __initdata in a non-__init function.
>
> All the functions within domain_build.c should have the attributes
> __init. However, it has been forgotten for half of them.
>
> I am planning to send a patch to enforce it using the Makefile rules.
I have such a work item (low) on my todo list too, actually.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 94563: regressions - FAIL
flight 94563 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/94563/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 9 debian-hvm-install fail REGR. vs. 94487 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 9 debian-install fail blocked in 94487 build-i386-rumpuserxen6 xen-buildfail like 94487 build-amd64-rumpuserxen 6 xen-buildfail like 94487 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 94487 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 94487 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94487 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94487 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-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass version targeted for testing: xen bab2bd8e222de9e596699ac080ea985af828c4c4 baseline version: xen ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83 Last test of basis94487 2016-05-16 15:18:47 Z2 days Failing since 94495 2016-05-17 00:15:00 Z2 days4 attempts Testing same since94563 2016-05-18 23:44:07 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Edgar E. Iglesias George Dunlap Ian Jackson Jan Beulich Peng Fan Stefano Stabellini Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass
Re: [Xen-devel] [PATCH v2] xen: add steal_clock support on x86
On 19/05/16 07:43, Juergen Gross wrote: > The pv_time_ops structure contains a function pointer for the > "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 > uses its own mechanism to account for the "stolen" time a thread wasn't > able to run due to hypervisor scheduling. > > Add support in Xen arch independent time handling for this feature by > moving it out of the arm arch into drivers/xen and remove the x86 Xen > hack. > > Signed-off-by: Juergen Gross After creating an arm cross environment I found a build error on arm. V3 coming soon. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3] xen: add steal_clock support on x86
The pv_time_ops structure contains a function pointer for the
"steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
uses its own mechanism to account for the "stolen" time a thread wasn't
able to run due to hypervisor scheduling.
Add support in Xen arch independent time handling for this feature by
moving it out of the arm arch into drivers/xen and remove the x86 Xen
hack.
Signed-off-by: Juergen Gross
---
V3: add #include to avoid build error on arm
V2: remove the x86 do_stolen_accounting() hack
---
arch/arm/xen/enlighten.c| 17 ++---
arch/x86/xen/time.c | 44 ++--
drivers/xen/time.c | 20
include/linux/kernel_stat.h | 1 -
include/xen/xen-ops.h | 1 +
kernel/sched/cputime.c | 10 --
6 files changed, 25 insertions(+), 68 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..9163b94 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -84,19 +84,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
}
EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
-static unsigned long long xen_stolen_accounting(int cpu)
-{
- struct vcpu_runstate_info state;
-
- BUG_ON(cpu != smp_processor_id());
-
- xen_get_runstate_snapshot(&state);
-
- WARN_ON(state.state != RUNSTATE_running);
-
- return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
-}
-
static void xen_read_wallclock(struct timespec64 *ts)
{
u32 version;
@@ -355,8 +342,8 @@ static int __init xen_guest_init(void)
register_cpu_notifier(&xen_cpu_notifier);
- pv_time_ops.steal_clock = xen_stolen_accounting;
- static_key_slow_inc(¶virt_steal_enabled);
+ xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a0a4e55..6be31df 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -11,8 +11,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
@@ -31,44 +29,6 @@
/* Xen may fire a timer up to this many ns early */
#define TIMER_SLOP 10
-#define NS_PER_TICK(10LL / HZ)
-
-/* snapshots of runstate info */
-static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
-
-/* unused ns of stolen time */
-static DEFINE_PER_CPU(u64, xen_residual_stolen);
-
-static void do_stolen_accounting(void)
-{
- struct vcpu_runstate_info state;
- struct vcpu_runstate_info *snap;
- s64 runnable, offline, stolen;
- cputime_t ticks;
-
- xen_get_runstate_snapshot(&state);
-
- WARN_ON(state.state != RUNSTATE_running);
-
- snap = this_cpu_ptr(&xen_runstate_snapshot);
-
- /* work out how much time the VCPU has not been runn*ing* */
- runnable = state.time[RUNSTATE_runnable] -
snap->time[RUNSTATE_runnable];
- offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];
-
- *snap = state;
-
- /* Add the appropriate number of ticks of stolen time,
- including any left-overs from last time. */
- stolen = runnable + offline + __this_cpu_read(xen_residual_stolen);
-
- if (stolen < 0)
- stolen = 0;
-
- ticks = iter_div_u64_rem(stolen, NS_PER_TICK, &stolen);
- __this_cpu_write(xen_residual_stolen, stolen);
- account_steal_ticks(ticks);
-}
/* Get the TSC speed from Xen */
static unsigned long xen_tsc_khz(void)
@@ -335,8 +295,6 @@ static irqreturn_t xen_timer_interrupt(int irq, void
*dev_id)
ret = IRQ_HANDLED;
}
- do_stolen_accounting();
-
return ret;
}
@@ -431,6 +389,8 @@ static void __init xen_time_init(void)
xen_setup_timer(cpu);
xen_setup_cpu_clockevents();
+ xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
}
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 7107842..2257b66 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
@@ -75,6 +76,15 @@ bool xen_vcpu_stolen(int vcpu)
return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
}
+static u64 xen_steal_clock(int cpu)
+{
+ struct vcpu_runstate_info state;
+
+ BUG_ON(cpu != smp_processor_id());
+ xen_get_runstate_snapshot(&state);
+ return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
+}
+
void xen_setup_runstate_info(int cpu)
{
struct vcpu_register_runstate_memory_area area;
@@ -86,3 +96,13 @@ void xen_setup_runstate_info(int cpu)
BUG();
}
+void __init xen_time_setup_guest(void)
+{
+ pv_time_ops.steal_clock = xen_steal_clock;
+
+ static_key_slow_inc(¶virt_steal_enabled);
+
[Xen-devel] [xen-unstable-smoke test] 94579: tolerable all pass - PUSHED
flight 94579 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94579/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 2bb230972c5ddb1ca823f47750b5d46a9d302d0e
baseline version:
xen bab2bd8e222de9e596699ac080ea985af828c4c4
Last test of basis94557 2016-05-18 19:02:02 Z0 days
Testing same since94579 2016-05-19 11:01:49 Z0 days1 attempts
People who touched revisions under test:
Jan Beulich
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=2bb230972c5ddb1ca823f47750b5d46a9d302d0e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
2bb230972c5ddb1ca823f47750b5d46a9d302d0e
+ branch=xen-unstable-smoke
+ revision=2bb230972c5ddb1ca823f47750b5d46a9d302d0e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x2bb230972c5ddb1ca823f47750b5d46a9d302d0e = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.
Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0
Hello,
On 18/05/16 17:32, Andrii Anisov wrote:
From: Oleksandr Dmytryshyn
This setting is used to adjust starting memory address allocated
for kernel Dom0. To use 'rambase_pfn' setting just add for example
'dom0_rambase_pfn=0x8' to the hypervisor command line. Note that
'dom0_rambase_pfn' should be aligned with the smallest memory chunk
which use xen memory allocator.
Why would a user want to allocate DOM0 RAM bank to a specific address?
If I understand correctly your patch, DOM0 will only able to allocate
one bank of the given size at the specific address. You also add this
possibility for guest domain (see patch #4) and try to control where the
guest memory will be allocated. This will increase a lot the chance of
the memory allocation to fail.
For instance, the RAM region requested for DOM0 may have been used to
allocate memory for Xen internal. So you need a way to reserve memory in
order to avoid Xen using it.
I expect most of the users who want to use direct memory mapped guest to
know the number of guests which will use this feature.
A such feature is only useful when pass-through a device to the guest on
platfom without SMMU, so it is by default insecure.
So I would suggest to create a new device-tree binding (or re-use an
actual one) to reserve memory region to be used for direct memory mapped
domain.
Those regions could have an identifier to be used later during the
allocation. This would avoid memory fragmentation, allow multiple RAM
bank for DOM0,...
Any opinions?
Signed-off-by: Oleksandr Dmytryshyn
---
xen/arch/arm/domain_build.c | 24 +---
xen/common/page_alloc.c | 68 +++--
xen/include/xen/mm.h| 2 ++
3 files changed, 75 insertions(+), 19 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 2937ff7..b48718d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -27,6 +27,9 @@
static unsigned int __initdata opt_dom0_max_vcpus;
integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+static u64 __initdata opt_dom0_rambase_pfn = 0;
+integer_param("dom0_rambase_pfn", opt_dom0_rambase_pfn);
+
int dom0_11_mapping = 1;
#define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
@@ -248,6 +251,8 @@ static void allocate_memory_11(struct domain *d, struct
kernel_info *kinfo)
const unsigned int min_order = get_order_from_bytes(MB(4));
struct page_info *pg;
unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
+u64 rambase_pfn = opt_dom0_rambase_pfn;
+paddr_t mem_size = kinfo->unassigned_mem;
int i;
bool_t lowmem = is_32bit_domain(d);
@@ -267,7 +272,7 @@ static void allocate_memory_11(struct domain *d, struct
kernel_info *kinfo)
{
for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
{
-pg = alloc_domheap_pages(d, order, MEMF_bits(bits));
+pg = alloc_domheap_pages_pfn(d, order, MEMF_bits(bits),
rambase_pfn);
if ( pg != NULL )
goto got_bank0;
}
@@ -284,16 +289,21 @@ static void allocate_memory_11(struct domain *d, struct
kernel_info *kinfo)
/* Now allocate more memory and fill in additional banks */
order = get_11_allocation_size(kinfo->unassigned_mem);
+if ( opt_dom0_rambase_pfn )
+rambase_pfn += (mem_size - kinfo->unassigned_mem) >> PAGE_SHIFT;
+
while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS )
{
-pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(32) : 0);
+pg = alloc_domheap_pages_pfn(d, order, lowmem ? MEMF_bits(32) : 0,
+ rambase_pfn);
From my understanding, when rambase_pfn is not 0, the memory must be
allocated contiguously at this specific address. So if the first call of
alloc_domheap_pages (see a bit above) as failed, then this one will
always fail because it means that someone has allocated some page in
this region.
if ( !pg )
{
order --;
if ( lowmem && order < min_low_order)
{
-D11PRINT("Failed at min_low_order, allow high allocations\n");
+if ( !opt_dom0_rambase_pfn )
+D11PRINT("Failed at min_low_order, allow high
allocations\n");
order = get_11_allocation_size(kinfo->unassigned_mem);
lowmem = false;
continue;
@@ -313,7 +323,8 @@ static void allocate_memory_11(struct domain *d, struct
kernel_info *kinfo)
if ( lowmem )
{
-D11PRINT("Allocation below bank 0, allow high allocations\n");
+if ( !opt_dom0_rambase_pfn )
+D11PRINT("Allocation below bank 0, allow high
allocations\n");
order = get_11_allocation_size(kinfo->unassigned_mem);
lowmem = false;
con
Re: [Xen-devel] [PATCH v3] xen: add steal_clock support on x86
On 05/19/2016 09:26 AM, Juergen Gross wrote: > The pv_time_ops structure contains a function pointer for the > "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 > uses its own mechanism to account for the "stolen" time a thread wasn't > able to run due to hypervisor scheduling. > > Add support in Xen arch independent time handling for this feature by > moving it out of the arm arch into drivers/xen and remove the x86 Xen > hack. > > Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky I think this also needs to be acked by (or at least copied to) generic Linux maintainers. > --- > arch/arm/xen/enlighten.c| 17 ++--- > arch/x86/xen/time.c | 44 ++-- > drivers/xen/time.c | 20 > include/linux/kernel_stat.h | 1 - > include/xen/xen-ops.h | 1 + > kernel/sched/cputime.c | 10 -- > 6 files changed, 25 insertions(+), 68 deletions(-) ... > } > diff --git a/drivers/xen/time.c b/drivers/xen/time.c > index 7107842..2257b66 100644 > --- a/drivers/xen/time.c > +++ b/drivers/xen/time.c > @@ -6,6 +6,7 @@ > #include > #include > > +#include > #include > #include > > @@ -75,6 +76,15 @@ bool xen_vcpu_stolen(int vcpu) > return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable; > } (Unrelated to this patch.) Should this include RUNSTATE_offline as well? -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] xtf: remove setting ROOT path in common.mk
Since it might be included from different paths that have different levels of nestedness. Also all makefiles that include common.mk already define ROOT on their own. Signed-off-by: Roger Pau Monné --- Cc: andrew.coop...@citrix.com --- build/common.mk | 1 - 1 file changed, 1 deletion(-) diff --git a/build/common.mk b/build/common.mk index 13c468e..6d4c8e8 100644 --- a/build/common.mk +++ b/build/common.mk @@ -1,4 +1,3 @@ -ROOT := $(abspath $(CURDIR)/../..) DESTDIR ?= $(ROOT)/dist PREFIX ?= $(ROOT) CC ?= gcc -- 2.7.4 (Apple Git-66) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] xtf: add launcher (+1 bugfix)
Hello, This series contains a bugfix for the build infrastructure and a basic launcher for XTF. Patches can also be found in the following git repo: git://xenbits.xen.org/people/royger/xen-test-framework.git launcher_v1 Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] xtf: add a launcher script
Add a simple script that can list the tests relevant to the current
environment and run them. In it's current form it's functionality is quite
limited, and consists in one of this two options:
- list: list tests relevant to the current environment. This information is
fetched from each test test-info.json and the output of `xl info`.
- test: launch a test (which can include creating several VMs) and report
the results back. The results are printed on the terminal, and the error
code is set appropriately (see backend/return_code.py for the list of
possible error codes).
The path to the directory where the tests are stored is mandatory, and
should always be passed to the script. As an example, I've used the
following bash runes in order to launch all tests suitable for my
environment:
for test in `dist/bin/xtf-launcher.py -f dist/tests/ -l`
do
dist/bin/xtf-launcher.py -f dist/tests/ -t $test
echo "Test $test return code: $?"
done
Which yields the following (trimmed for convenience):
Parsing config from dist/tests/cpuid/test-pv64-cpuid.cfg
test-pv64-cpuid took 0s
Parsing config from dist/tests/cpuid/test-pv32pae-cpuid.cfg
test-pv32pae-cpuid took 0s
Parsing config from dist/tests/cpuid/test-hvm64-cpuid.cfg
libxl: warning: libxl_dm.c:1486:libxl__build_device_model_args_new: Could not
find user xen-qemuuser-shared, starting QEMU as root
test-hvm64-cpuid took 0s
Parsing config from dist/tests/cpuid/test-hvm32pae-cpuid.cfg
libxl: warning: libxl_dm.c:1486:libxl__build_device_model_args_new: Could not
find user xen-qemuuser-shared, starting QEMU as root
test-hvm32pae-cpuid took 0s
Parsing config from dist/tests/cpuid/test-hvm32pse-cpuid.cfg
libxl: warning: libxl_dm.c:1486:libxl__build_device_model_args_new: Could not
find user xen-qemuuser-shared, starting QEMU as root
test-hvm32pse-cpuid took 0s
Parsing config from dist/tests/cpuid/test-hvm32-cpuid.cfg
libxl: warning: libxl_dm.c:1486:libxl__build_device_model_args_new: Could not
find user xen-qemuuser-shared, starting QEMU as root
test-hvm32-cpuid took 0s
test-pv64-cpuid:SUCCESS
test-hvm64-cpuid: SUCCESS
test-hvm32-cpuid: SUCCESS
test-hvm32pse-cpuid:SUCCESS
test-hvm32pae-cpuid:SUCCESS
test-pv32pae-cpuid: SUCCESS
Test cpuid return code: 0
[...]
Note that the specific runes to interact with xl have been placed in a
separate file, and that other backends could be easily added provided that
config files suitable for them are also added to XTF tests. A new
--toolstack option should be added then in order to tell the launcher which
toolstack to use.
Signed-off-by: Roger Pau Monné
---
Cc: andrew.coop...@citrix.com
Cc: ian.jack...@eu.citrix.com
Cc: wei.l...@citrix.com
Cc: anshul.mak...@citrix.com
---
Makefile | 2 +-
tools/launcher/Makefile| 12
tools/launcher/backends/__init__.py| 0
tools/launcher/backends/return_code.py | 28 +
tools/launcher/backends/xl.py | 59 +++
tools/launcher/xtf-launcher.py | 101 +
6 files changed, 201 insertions(+), 1 deletion(-)
create mode 100644 tools/launcher/Makefile
create mode 100644 tools/launcher/backends/__init__.py
create mode 100644 tools/launcher/backends/return_code.py
create mode 100644 tools/launcher/backends/xl.py
create mode 100644 tools/launcher/xtf-launcher.py
diff --git a/Makefile b/Makefile
index fd8c3e0..eda9a25 100644
--- a/Makefile
+++ b/Makefile
@@ -9,7 +9,7 @@ all:
.PHONY: install
install:
- @for D in $(wildcard tests/*); do \
+ @for D in $(wildcard tests/* tools/*); do \
[ ! -e $$D/Makefile ] && continue; \
$(MAKE) -C $$D install; \
done
diff --git a/tools/launcher/Makefile b/tools/launcher/Makefile
new file mode 100644
index 000..2c07604
--- /dev/null
+++ b/tools/launcher/Makefile
@@ -0,0 +1,12 @@
+ROOT := $(abspath $(CURDIR)/../..)
+
+include $(ROOT)/build/common.mk
+
+TOOLS := xtf-launcher.py
+BACKENDS := __init__.py xl.py return_code.py
+
+install: $(TOOLS) $(addprefix backends/,$(BACKENDS))
+ @mkdir -p $(DESTDIR)/bin
+ @mkdir -p $(DESTDIR)/bin/backends
+ install -m775 -p $(TOOLS) $(DESTDIR)/bin
+ install -m664 -p $(addprefix backends/,$(BACKENDS))
$(DESTDIR)/bin/backends/
diff --git a/tools/launcher/backends/__init__.py
b/tools/launcher/backends/__init__.py
new file mode 100644
index 000..e69de29
diff --git a/tools/launcher/backends/return_code.py
b/tools/launcher/backends/return_code.py
new file mode 100644
index 000..509460a
--- /dev/null
+++ b/tools/launcher/backends/return_code.py
@@ -0,0 +1,28 @@
+#
+# Error codes for XTF launcher
+#
+
+# All went fine.
+SUCCESS = 0
+
+# Bug in the launcher.
+ERROR_LAUNCHER = 1
+
+# Test cannot be completed.
+ERROR_SKIP = 2
+
+# Bug in the test code or environment.
+ERROR_ERROR = 3
+
+# Bug in the code under test.
+ERROR_FAILURE = 4
+
+def code_to_str(code):
+err_trans = {
+
Re: [Xen-devel] [PATCH RFC 15/18] arm: Add ability to relocate Xen in over 4GB space
Hello,
On 18/05/16 17:32, Andrii Anisov wrote:
From: Iurii Konovalenko
Move Xen to the end of physical memory
Can you explain why? As Ian campbell said on the previous version sent
last year [1], Xen itself (i.e .text, .bss and .data, not the xenheap
itself) is at most 2MB. Are your constraints such that at a 4GB-2MB
(i.e. 4096M) of lowmem would not be acceptable?
Also, this patch looks very similar to the one you have sent last year
[2]. Most of the comments in this thread are still valid, so I will not
repeat them here.
Regards,
Signed-off-by: Iurii Konovalenko
---
xen/Rules.mk | 1 +
xen/arch/arm/arm32/head.S | 21 -
xen/arch/arm/domain_build.c| 2 +-
xen/arch/arm/platforms/omap5.c | 17 ++---
xen/arch/arm/platforms/rcar2.c | 9 -
xen/arch/arm/setup.c | 21 ++
++-
xen/arch/arm/smpboot.c | 33 +
7 files changed, 93 insertions(+), 11 deletions(-)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index feb08d6..fbd34a5 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -64,6 +64,7 @@ CFLAGS-$(HAS_PCI) += -DHAS_PCI
CFLAGS-$(HAS_IOPORTS) += -DHAS_IOPORTS
CFLAGS-$(HAS_PDX) += -DHAS_PDX
CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(ARM32_RELOCATE_OVER_4GB) += -DARM32_RELOCATE_OVER_4GB
ifneq ($(max_phys_cpus),)
CFLAGS-y+= -DMAX_PHYS_CPUS=$(max_phys_cpus)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index e1f29bd..a644d6d 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -262,8 +262,21 @@ cpu_init_done:
add r4, r4, r10/* r4 := paddr (boot_pagetable) */
mov r5, #0 /* r4:r5 is paddr (boot_pagetable) */
mcrr CP64(r4, r5, HTTBR)
+#ifdef ARM32_RELOCATE_OVER_4GB
+teq r7, #0
+beq 1f /* construct pagetable if CPU0 */
-/* Setup boot_pgtable: */
+/*Skip constructing TLBs for secondary CPUs, use constracted by CPU0*/
+PRINT("- Skip construction pagetable, using CPU0 table @")
+mov r0, r5
+blputn
+mov r0, r4
+blputn
+PRINT(" -\r\n")
+bne skip_constructing
+#endif
+
+1: /* Setup boot_pgtable: */
ldr r1, =boot_second
add r1, r1, r10/* r1 := paddr (boot_second) */
@@ -346,6 +359,7 @@ virtphys_clash:
PRINT("- Unable to build boot page tables - virt and phys addresses clash.
-\r\n")
b fail
+skip_constructing:
1:
PRINT("- Turning on paging -\r\n")
@@ -427,6 +441,11 @@ paging:
* setup in init_secondary_pagetables. */
ldr r4, =init_ttbr /* VA of HTTBR value stashed by CPU 0 */
+#ifdef ARM32_RELOCATE_OVER_4GB
+ldr r1, =_start
+sub r4, r1
+add r4, #BOOT_RELOC_VIRT_START
+#endif
ldrd r4, r5, [r4] /* Actual value */
dsb
mcrr CP64(r4, r5, HTTBR)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index b48718d..f06792e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1487,7 +1487,7 @@ static void __init find_gnttab_region(struct domain *d,
if ( (kinfo->gnttab_size >> PAGE_SHIFT) < max_grant_frames )
panic("Cannot find a space for the grant table region\n");
-#ifdef CONFIG_ARM_32
+#if defined(CONFIG_ARM_32) && !defined(ARM32_RELOCATE_OVER_4GB)
/*
* The gnttab region must be under 4GB in order to work with DOM0
* using short page table.
diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
index a49ba62..fe77397 100644
--- a/xen/arch/arm/platforms/omap5.c
+++ b/xen/arch/arm/platforms/omap5.c
@@ -25,6 +25,10 @@
#include
#include
+#ifdef ARM32_RELOCATE_OVER_4GB
+extern paddr_t xen_relocation_offset;
+#endif
+
static uint16_t num_den[8][2] = {
{ 0, 0 }, /* not used */
{ 26 * 64, 26 * 125 }, /* 12.0 Mhz */
@@ -132,9 +136,16 @@ static int __init omap5_smp_init(void)
}
printk("Set AuxCoreBoot1 to %"PRIpaddr" (%p)\n",
- __pa(init_secondary), init_secondary);
-writel(__pa(init_secondary), wugen_base + OMAP_AUX_CORE_BOOT_1_OFFSET);
-
+ __pa(init_secondary)
+#ifdef ARM32_RELOCATE_OVER_4GB
+- xen_relocation_offset
+#endif
+ , init_secondary);
+writel(__pa(init_secondary)
+#ifdef ARM32_RELOCATE_OVER_4GB
+- xen_relocation_offset
+#endif
+ , wugen_base + OMAP_AUX_CORE_BOOT_1_OFFSET);
printk("Set AuxCoreBoot0 to 0x20\n");
writel(0x20, wugen_base + OMAP_AUX_CORE_BOOT_0_OFFSET);
diff --git a/xen/arch/arm/platforms/rcar2.c b/xen/arch/arm/platforms/rcar2.c
index bb25751..26973f6 100644
--- a/xen/arch/arm/platforms/rcar2.c
+++ b/xen/arch/arm/platform
Re: [Xen-devel] [PATCH 1/2] xtf: remove setting ROOT path in common.mk
On 19/05/16 14:46, Roger Pau Monne wrote: > Since it might be included from different paths that have different levels > of nestedness. Also all makefiles that include common.mk already define ROOT > on their own. > > Signed-off-by: Roger Pau Monné I really need to work on improving the build system. This one is already creaking at the seams. LGTM - Reviewed-by: Andrew Cooper and committed. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] xen: add steal_clock support on x86
On 19/05/16 15:26, Juergen Gross wrote:
> The pv_time_ops structure contains a function pointer for the
> "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
> uses its own mechanism to account for the "stolen" time a thread wasn't
> able to run due to hypervisor scheduling.
>
> Add support in Xen arch independent time handling for this feature by
> moving it out of the arm arch into drivers/xen and remove the x86 Xen
> hack.
>
> Signed-off-by: Juergen Gross
Sorry, forgot scheduling maintainer. Added.
Juergen
> ---
> V3: add #include to avoid build error on arm
> V2: remove the x86 do_stolen_accounting() hack
> ---
> arch/arm/xen/enlighten.c| 17 ++---
> arch/x86/xen/time.c | 44 ++--
> drivers/xen/time.c | 20
> include/linux/kernel_stat.h | 1 -
> include/xen/xen-ops.h | 1 +
> kernel/sched/cputime.c | 10 --
> 6 files changed, 25 insertions(+), 68 deletions(-)
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 75cd734..9163b94 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -84,19 +84,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
> }
> EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
>
> -static unsigned long long xen_stolen_accounting(int cpu)
> -{
> - struct vcpu_runstate_info state;
> -
> - BUG_ON(cpu != smp_processor_id());
> -
> - xen_get_runstate_snapshot(&state);
> -
> - WARN_ON(state.state != RUNSTATE_running);
> -
> - return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
> -}
> -
> static void xen_read_wallclock(struct timespec64 *ts)
> {
> u32 version;
> @@ -355,8 +342,8 @@ static int __init xen_guest_init(void)
>
> register_cpu_notifier(&xen_cpu_notifier);
>
> - pv_time_ops.steal_clock = xen_stolen_accounting;
> - static_key_slow_inc(¶virt_steal_enabled);
> + xen_time_setup_guest();
> +
> if (xen_initial_domain())
> pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
>
> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
> index a0a4e55..6be31df 100644
> --- a/arch/x86/xen/time.c
> +++ b/arch/x86/xen/time.c
> @@ -11,8 +11,6 @@
> #include
> #include
> #include
> -#include
> -#include
> #include
> #include
> #include
> @@ -31,44 +29,6 @@
>
> /* Xen may fire a timer up to this many ns early */
> #define TIMER_SLOP 10
> -#define NS_PER_TICK (10LL / HZ)
> -
> -/* snapshots of runstate info */
> -static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);
> -
> -/* unused ns of stolen time */
> -static DEFINE_PER_CPU(u64, xen_residual_stolen);
> -
> -static void do_stolen_accounting(void)
> -{
> - struct vcpu_runstate_info state;
> - struct vcpu_runstate_info *snap;
> - s64 runnable, offline, stolen;
> - cputime_t ticks;
> -
> - xen_get_runstate_snapshot(&state);
> -
> - WARN_ON(state.state != RUNSTATE_running);
> -
> - snap = this_cpu_ptr(&xen_runstate_snapshot);
> -
> - /* work out how much time the VCPU has not been runn*ing* */
> - runnable = state.time[RUNSTATE_runnable] -
> snap->time[RUNSTATE_runnable];
> - offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];
> -
> - *snap = state;
> -
> - /* Add the appropriate number of ticks of stolen time,
> -including any left-overs from last time. */
> - stolen = runnable + offline + __this_cpu_read(xen_residual_stolen);
> -
> - if (stolen < 0)
> - stolen = 0;
> -
> - ticks = iter_div_u64_rem(stolen, NS_PER_TICK, &stolen);
> - __this_cpu_write(xen_residual_stolen, stolen);
> - account_steal_ticks(ticks);
> -}
>
> /* Get the TSC speed from Xen */
> static unsigned long xen_tsc_khz(void)
> @@ -335,8 +295,6 @@ static irqreturn_t xen_timer_interrupt(int irq, void
> *dev_id)
> ret = IRQ_HANDLED;
> }
>
> - do_stolen_accounting();
> -
> return ret;
> }
>
> @@ -431,6 +389,8 @@ static void __init xen_time_init(void)
> xen_setup_timer(cpu);
> xen_setup_cpu_clockevents();
>
> + xen_time_setup_guest();
> +
> if (xen_initial_domain())
> pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
> }
> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> index 7107842..2257b66 100644
> --- a/drivers/xen/time.c
> +++ b/drivers/xen/time.c
> @@ -6,6 +6,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -75,6 +76,15 @@ bool xen_vcpu_stolen(int vcpu)
> return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
> }
>
> +static u64 xen_steal_clock(int cpu)
> +{
> + struct vcpu_runstate_info state;
> +
> + BUG_ON(cpu != smp_processor_id());
> + xen_get_runstate_snapshot(&state);
> + return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
> +}
> +
> void xe
Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus
On Thu, May 19, 2016 at 12:21:57PM +0200, Dario Faggioli wrote:
> Since, AFAIUI, you're interested in non-Linux guests' perspective, I'm
> adding Roger (and avoiding trimming, for his benefit), who can tell us
> what he thinks of this all, from the FreeBSD point of view.
Thanks, AFAIK vcpu_runstate_info is only used by Linux ATM? (maybe Windows?)
FreeBSD doesn't do stolen time accounting at all, and (although I would
really like to see this implemented) I don't foresee myself adding this in
the near future. That's mainly because FreeBSD doesn't have the necessary
scheduler hooks, so it's not only implementing the Xen side of it, it needs
to be plumbed through the scheduler and that doesn't look like an easy task.
NetBSD also doesn't seem to do it, and OpenBSD just gained basic Xen
support, so no stolen time accounting there also.
> On Thu, May 19, 2016 at 10:49 AM, Juergen Gross wrote:
> > On 19/05/16 10:09, Andrew Cooper wrote:
> >> On 19/05/2016 08:53, Juergen Gross wrote:
> >>> A guest kernel can use the vcpu_op hypercall sub-op
> >>> VCPUOP_register_runstate_memory_area to get a copy of the
> >>> vcpu_runstate_info of a vcpu mapped into its memory. As this structure
> >>> has no update indicator it is only save to be read by the vcpu it is
> >>> containing the runstate information of.
> >>>
> >>> Being able to read the runstate info of another cpu is required e.g.
> >>> by the Linux kernel to be able to calculate vruntime: see
> >>>
> >>> http://lists.xen.org/archives/html/xen-devel/2016-05/msg01790.html
> >>>
> >>> I'd suggest to add an "update in progress" indicator in the highest
> >>> bit of vcpu_runstate_info->state_entry_time as this structure element is
> >>> already used to detect vcpu scheduling when vcpu_runstate_info is read
> >>> by the owning vcpu.
> >>>
> >>> The question is how to enable setting this indicator, as the guest must
> >>> be able to cope with it (I believe the Linux kernel would just run fine,
> >>> but we can't be sure this is true for all guests).
> >>>
> >>> I see the following possible solutions:
> >>>
> >>> a) Introduce a new vcpu_op hypercall sub-op for mapping the
> >>>vcpu_runstate_info with update indicator support (a guest supporting
> >>>this would try the new sub-op first and could fall back to
> >>>VCPUOP_register_runstate_memory_area in case of ENOSYS).
> >>>
> >>> b) Add a virtual MSR to switch on the feature (not being able to set the
> >>>appropriate bit would indicate the feature not being available). This
> >>>is the variant KVM is using. Does ARM have something like MSRs?
So I assume the vcpu_runstate_info structure is shared between Xen and KVM,
just like the PV time info structure?
> >>> c) Add another hypercall to switch on the feature (similar to
> >>>XENVER_get_features we could have a XENVER_set_features).
> >>>
> >>> Any preferences?
> >>
> >> However, irrespective of how you signal the request for new behaviour,
> >> you should see about using a lockless clock rather than a single bit, as
> >> a single bit can't indicate the case where a complete update has
> >> occurred between two samplings. This will probably require an extension
> >> to the current implementation, at which point you might be able to add a
> >> capability field as well.
> >
> > That's the reason I've chosen state_entry_time as the home for the new
> > bit. state_entry_time is guaranteed to change between two updates. So
> > the logic would look like the following:
> >
> > do {
> > old_entry_time = READ_ONCE(r->state_entry_time);
> > rmb();
> > new_state = READ_ONCE(*r);
> > rmb();
> > } while (new_state.state_entry_time != old_entry_time ||
> > (old_entry_time >> 63));
> >
> >> Alternatively, the easiest way will probably be to add a new VMASSIST,
> >> which allows the guest to opt into the new behaviour.
> >
> > Aah, nice. Yes, this seems to be a sensible option.
> >
> FWIW, this looks a good approach to me as well.
I don't have a problem with this, I would just like to use whatever KVM uses
in order to be able to reduce code duplication if I ever implement this on
FreeBSD.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0
> Why would a user want to allocate DOM0 RAM bank to a specific address? > > If I understand correctly your patch, DOM0 will only able to allocate one > bank of the given size at the specific address. You also add this possibility > for guest domain (see patch #4) and try to control where the guest memory > will be allocated. This will increase a lot the chance of the memory > allocation to fail. > > For instance, the RAM region requested for DOM0 may have been used to > allocate memory for Xen internal. So you need a way to reserve memory in > order to avoid Xen using it. > > I expect most of the users who want to use direct memory mapped guest to know > the number of guests which will use this feature. > > A such feature is only useful when pass-through a device to the guest on > platfom without SMMU, so it is by default insecure. > > So I would suggest to create a new device-tree binding (or re-use an actual > one) to reserve memory region to be used for direct memory mapped domain. > > Those regions could have an identifier to be used later during the > allocation. This would avoid memory fragmentation, allow multiple RAM bank > for DOM0,... > > Any opinions? Case 1: Dom0 is driver domain: There is a Ducati firmware which runs on dedicated M4 core and decodes video. This firmware uses hardcoded physical addresses for graphics buffers. Those addresses should be inside address-space of the driver domain (Dom0). Ducati firmware is proprietary and we have no ability to rework it. So Dom0 kernel should be placed to the configured address (to the DOM0 RAM bank with specific address). Case 2: Dom0 is Thin and DomD is driver domain. All is the same: Ducati firmware requires special (hardcoded) addresses. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Supporting consistency of vcpu_runstate_info across cpus
On 19/05/16 12:48, Stefano Stabellini wrote: > On Thu, 19 May 2016, Jan Beulich wrote: > On 19.05.16 at 12:40, wrote: >>> On Thu, 19 May 2016, Juergen Gross wrote: > Alternatively, the easiest way will probably be to add a new VMASSIST, > which allows the guest to opt into the new behaviour. Aah, nice. Yes, this seems to be a sensible option. >>> >>> If you are referring to VM_ASSIST, it is only available on x86. I >>> suggest we use a feature flag instead. >> >> A feature flag can only be checked by the guest, not set. How >> about enabling VMASSIST for ARM? > > Sure Stefano, if you want I can do this when adding the VMASSIST option. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.7 3/3] docs/feature: Tweaks to the feature document template
During review of the migration feature doc, some changes were made which should have been reflected in the template. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu --- docs/features/template.pandoc | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/features/template.pandoc b/docs/features/template.pandoc index 7698291..82881e3 100644 --- a/docs/features/template.pandoc +++ b/docs/features/template.pandoc @@ -29,22 +29,22 @@ Architecture(s): e.g. x86, arm A short description the feature, similar to an abstract for a paper/presentation. -# User information +# User details Information for a user attempting to use the feature. Should include how to enable the feature (is it enabled by default? If not, how to turn it on?), and how to interact with the feature (typically via `xl`). +# Technical details + +Information for a developer or power user. Should include where to look +in-tree for detailed documents and code. + # Limitations Information concerning incompatibilities with other features or hardware combinations. -# Technical information - -Information for a developer or power user. Should include where to look -in-tree for detailed documents and code. - # Testing Information concerning how to properly test changes affecting this feature. -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.7 1/3] docs/build: Avoid using multi-target pattern rules
Multi-target non-pattern rules and Multi-target pattern rules behave rather differently. From `Pattern Intro': Pattern rules may have more than one target. Unlike normal rules, this does not act as many different rules with the same prerequisites and commands. If a pattern rule has multiple targets, `make' knows that the rule's commands are responsible for making all of the targets. The commands are executed only once to make all the targets. The intended use of the multi-target pattern rules was to avoid repeating the identical recipe multiple times. The issue can be demonstrated with the generation of documentation from pandoc source. ./xen.git$ touch docs/features/template.pandoc ./xen.git$ make -C docs/ # Regenerates html/features/template.html ./xen.git$ make -C docs/ # Regenerates txt/features/template.txt ./xen.git$ make -C docs/ # Regenerates pdf/features/template.pdf To work around this, there need to be three distinct rules, so the execution of one recipe doesn't short ciruit the others. To avoid copy&paste duplication, introduce a metarule, and evalute it for each document target. As $(PANDOC) is used to generate documentation from different source types, the metarule can be extended to also encompas the rule to create pdfs from markdown. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson Release-acked-by: Wei Liu --- docs/Makefile | 24 +--- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/docs/Makefile b/docs/Makefile index b9da605..e2537e8 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -180,22 +180,24 @@ txt/%.txt: %.markdown @$(INSTALL_DIR) $(@D) $(INSTALL_DATA) $< $@ -pdf/%.pdf: %.markdown -ifneq ($(PANDOC),) - @$(INSTALL_DIR) $(@D) - $(PANDOC) --number-sections --toc --standalone $< --output $@ -else - @echo "pandoc not installed; skipping $@" -endif +# Metarule for generating pandoc rules. +define GENERATE_PANDOC_RULE +# $(1) is the target documentation format. $(2) is the source format. -pdf/%.pdf txt/%.txt html/%.html: %.pandoc +$(1)/%.$(1): %.$(2) ifneq ($(PANDOC),) - @$(INSTALL_DIR) $(@D) - $(PANDOC) --number-sections --toc --standalone $< --output $@ + @$(INSTALL_DIR) $$(@D) + $(PANDOC) --number-sections --toc --standalone $$< --output $$@ else - @echo "pandoc not installed; skipping $@" + @echo "pandoc not installed; skipping $$@" endif +endef +$(eval $(call GENERATE_PANDOC_RULE,pdf,pandoc)) # pdf/%.pdf: %.pandoc +$(eval $(call GENERATE_PANDOC_RULE,txt,pandoc)) # txt/%.txt: %.pandoc +$(eval $(call GENERATE_PANDOC_RULE,html,pandoc)) # html/%.html: %.pandoc +$(eval $(call GENERATE_PANDOC_RULE,pdf,markdown)) # pdf/%.pdf: %.markdown + ifeq (,$(findstring clean,$(MAKECMDGOALS))) $(XEN_ROOT)/config/Docs.mk: $(error You have to run ./configure before building docs) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Resend: [PATCH] v3 - Add exclusive locking option to block-iscsi
On Thu, May 19, 2016 at 11:29:32AM +1000, Steven Haigh wrote:
> On 2016-05-09 14:22, Steven Haigh wrote:
> > On 2016-05-05 15:52, Steven Haigh wrote:
> > > On 2016-05-05 12:32, Steven Haigh wrote:
> > > > Overview
> > > >
> > > > If you're using iSCSI, you can mount a target by multiple Dom0
> > > > machines on the same target. For non-cluster aware filesystems, this
> > > > can lead to disk corruption and general bad times by all. The iSCSI
> > > > protocol allows the use of persistent reservations as per the SCSI
> > > > disk spec. Low level SCSI commands for locking are handled by the
> > > > sg_persist program (bundled with sg3_utils package in EL).
> > > >
> > > > The aim of this patch is to create a 'locktarget=y' option specified
> > > > within the disk 'target' command for iSCSI to lock the target in
> > > > exclusive mode on VM start with a key generated from the local
> > > > systems
> > > > IP, and release this lock on the shutdown of the DomU.
> > > >
> > > > Example Config:
> > > > disk=
> > > > ['script=block-iscsi,vdev=xvda,target=iqn=iqn.1986-03.com.sun:02:mytarget,portal=iscsi.example.com,locktarget=y']
> > > >
> > > > In writing this, I have also re-factored parts of the script to put
> > > > some things in what I believe to be a better place to make expansion
> > > > easier. This is mainly in removing functions that purely call other
> > > > functions with no actual code execution.
> > > >
> > > > Signed-off-by: Steven Haigh
> > > >
> > > > (on a side note, first time I've submitted a patch to the list
> > > > and I'm
> > > > currently stuck on a webmail client, so apologies in advance if this
> > > > all goes wrong ;)
> > >
> > > Changes in v2:
> > > Bugfix: Call find_device to locate the /dev/sdX component of the iSCSI
> > > target before trying to run unlock_device().
> > >
> > > Apologies for this oversight.
> > >
> >
> > Changes in v3:
> > * Split the block-iscsi cleanup into a seperate patch
> > (block-iscsi-locking-v3_01_simplify_block-iscsi.patch).
> > * Add locking in second patch file
> > (block-iscsi-locking-v3_02_add_locking.patch)
>
> Resend of patches.
IMHO, if those patches are going to be committed to Xen they need to be
sent using git, they are (at least) missing a proper changelog.
> There was a mention of having to add further documentation to
> xl-disk-configuration.txt - however there are no mentions of block-iscsi
> script within the documentation to add. As such, it probably would be out of
> place to add things here.
Hm, I don't think we have ever added specific block-scripts configuration
options to xl-disk-configuration.txt. What I did was to instead add this
information at the top of the script file itself, and the locktarget option
should be documented there together with the other options. Sadly I see that
the 'multipath' option did not add the documentation.
> The locktarget option is presented directly to the block-iscsi script and
> not evaluated anywhere outside this script.
>
> --
> Steven Haigh
>
> Email: net...@crc.id.au
> Web: https://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> --- block-iscsi.orig2016-05-09 15:12:02.489495212 +1000
> +++ block-iscsi 2016-05-09 15:16:35.447480532 +1000
> @@ -31,16 +31,6 @@
> echo $1 | sed "s/^\("$2"\)//"
> }
>
> -check_tools()
> -{
> -if ! command -v iscsiadm > /dev/null 2>&1; then
> -fatal "Unable to find iscsiadm tool"
> -fi
> -if [ "$multipath" = "y" ] && ! command -v multipath > /dev/null 2>&1;
> then
> -fatal "Unable to find multipath"
> -fi
> -}
> -
> # Sets the following global variables based on the params field passed in as
> # a parameter: iqn, portal, auth_method, user, multipath, password
> parse_target()
> @@ -52,12 +42,18 @@
> case $param in
> iqn=*)
> iqn=$(remove_label $param "iqn=")
> +if ! command -v iscsiadm > /dev/null 2>&1; then
> +fatal "Could not find iscsiadm tool."
> +fi
> ;;
> portal=*)
> portal=$(remove_label $param "portal=")
> ;;
> multipath=*)
> multipath=$(remove_label $param "multipath=")
This is wrong, multipath can have the values 'y' or 'n' only, and there's a
check below that makes sure of that. Here you would be checking if
'multipath' is available even if multipath=n has been set.
IMHO, I think that having a separation between the option parser and the
tools availability check makes sense, and avoids mistakes like this.
> +if ! command -v multipath > /dev/null 2>&1; then
> +fatal "Multipath selected, but no multipath tools found"
> +fi
> ;;
> esac
> done
> @@ -96,40 +92,6 @@
> fi
> }
>
> -# Attaches the target $iqn in $portal and sets $dev to point to the
> -# multipath device
> -attach()
> -{
> -do_or_die iscsiadm -m node --targetname "$iqn" -p "$portal" --login >
[Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc
Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded \n in
the signature checking paragraph.
/usr/bin/pandoc --number-sections --toc --standalone misc/xsplice.markdown
--output pdf/misc/xsplice.pdf
! Undefined control sequence.
l.1085 appended\textasciitilde{}\n
Surround the string in backticks to make it verbatim text.
While altering this file, strip the substantial quantity of trailing
whitespace.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Konrad Rzeszutek Wilk
---
docs/misc/xsplice.markdown | 304 ++---
1 file changed, 152 insertions(+), 152 deletions(-)
diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
index 4a98be1..80f8bc7 100644
--- a/docs/misc/xsplice.markdown
+++ b/docs/misc/xsplice.markdown
@@ -90,18 +90,18 @@ As example we will assume the hypervisor does not have
XSA-132 (see
the hypervisor with it. The original code looks as so:
- 48 89 e0 mov%rsp,%rax
- 48 25 00 80 ff ff and$0x8000,%rax
+ 48 89 e0 mov%rsp,%rax
+ 48 25 00 80 ff ff and$0x8000,%rax
while the new patched hypervisor would be:
- 48 c7 45 b8 00 00 00 00 movq $0x0,-0x48(%rbp)
- 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
- 48 c7 45 c8 00 00 00 00 movq $0x0,-0x38(%rbp)
- 48 89 e0 mov%rsp,%rax
- 48 25 00 80 ff ff and$0x8000,%rax
+ 48 c7 45 b8 00 00 00 00 movq $0x0,-0x48(%rbp)
+ 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
+ 48 c7 45 c8 00 00 00 00 movq $0x0,-0x38(%rbp)
+ 48 89 e0 mov%rsp,%rax
+ 48 25 00 80 ff ff and$0x8000,%rax
This is inside the arch_do_domctl. This new change adds 21 extra
@@ -113,8 +113,8 @@ As such we could simplify this problem by only patching the
site
which calls arch_do_domctl:
-do_domctl:
- e8 4b b1 05 00 callq 82d08015fbb9
+do_domctl:
+ e8 4b b1 05 00 callq 82d08015fbb9
with a new address for where the new `arch_do_domctl` would be (this
@@ -128,8 +128,8 @@ Patching the offset in `hypercall_table` for `do_domctl:
- 82d08024d490: 79 30
- 82d08024d492: 10 80 d0 82 ff ff
+ 82d08024d490: 79 30
+ 82d08024d492: 10 80 d0 82 ff ff
@@ -172,9 +172,9 @@ from that). Patching the offset in `hypercall_table` for
the old
`do_xen_version` (82d080112f9e )
- 82d08024b270 :
- ...
- 82d08024b2f8: 9e 2f 11 80 d0 82 ff ff
+ 82d08024b270 :
+ ...
+ 82d08024b2f8: 9e 2f 11 80 d0 82 ff ff
@@ -187,17 +187,17 @@ An alternative solution would be to patch insert a
trampoline in the
old `do_xen_version' function to directly jump to the new `do_xen_version`.
- 82d080112f9e do_xen_version:
- 82d080112f9e: 48 c7 c0 da ff ff ffmov
$0xffda,%rax
- 82d080112fa5: 83 ff 09cmp$0x9,%edi
- 82d080112fa8: 0f 87 24 05 00 00 ja 82d0801134d2 ;
do_xen_version+0x534
+ 82d080112f9e do_xen_version:
+ 82d080112f9e: 48 c7 c0 da ff ff ffmov
$0xffda,%rax
+ 82d080112fa5: 83 ff 09cmp$0x9,%edi
+ 82d080112fa8: 0f 87 24 05 00 00 ja 82d0801134d2 ;
do_xen_version+0x534
with:
- 82d080112f9e do_xen_version:
- 82d080112f9e: e9 XX YY ZZ QQ jmpq [new do_xen_version]
+ 82d080112f9e do_xen_version:
+ 82d080112f9e: e9 XX YY ZZ QQ jmpq [new do_xen_version]
which would lessen the amount of patching to just one location.
@@ -296,15 +296,15 @@ The `.xsplice.funcs` contains an array of
xsplice_patch_func structures
which describe the functions to be patched:
-struct xsplice_patch_func {
-const char *name;
-void *new_addr;
-void *old_addr;
-uint32_t new_size;
-uint32_t old_size;
-uint8_t version;
-uint8_t opaque[31];
-};
+struct xsplice_patch_func {
+const char *name;
+void *new_addr;
+void *old_addr;
+uint32_t new_size;
+uint32_t old_size;
+uint8_t version;
+uint8_t opaque[31];
+};
The size of the structure is 64 bytes on 64-bit hypervisors. It will be
@@ -345,33 +345,33 @@ to `old_addr`.
A simple example of what a payload file can be:
-/* MUST be in sync with hypervisor. */
-struct xsplice_patch_func {
-const char *name;
-void *new_addr;
-void *old_addr;
-uint32_t new_size;
-uint32_t old_size;
+/* MUST be in sync with hypervisor. */
+struct xsplice_patch_func {
+const char *name;
+void *new_addr;
+void *old_addr;
+uint32_t new_size;
+uint32_t old_size;
uint8_t version;
-uint8_t pad[31];
-};
+uint8_t pad[31];
+};
-/* Our replacement function for xen_extra_version.
[Xen-devel] (no subject)
, Ian Jackson , Jan Beulich , Konrad Rzeszutek Wilk , Stefano Stabellini , Tim Deegan , Wei Liu Bcc: Subject: Bump library names just after branching Reply-To: Hello, Currently we bump the shared library names just before the release, so ATM xen-unstable is still using the library names from the 4.6 release. This is an issue if someone wants to install both Xen 4.6 and xen-unstable in the same box (unless you use a different prefix/DESTDIR), because libraries from xen-unstable will replace the stable ones. IMHO, it would make more sense to bump the library names just *after* we branch and open the tree for development again. We could even have the library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so that we don't need to go around the different library makefiles bumping the versions manually. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0
Hello Oleksandr, On 19/05/16 14:58, Oleksandr Dmytryshyn wrote: Why would a user want to allocate DOM0 RAM bank to a specific address? If I understand correctly your patch, DOM0 will only able to allocate one bank of the given size at the specific address. You also add this possibility for guest domain (see patch #4) and try to control where the guest memory will be allocated. This will increase a lot the chance of the memory allocation to fail. For instance, the RAM region requested for DOM0 may have been used to allocate memory for Xen internal. So you need a way to reserve memory in order to avoid Xen using it. I expect most of the users who want to use direct memory mapped guest to know the number of guests which will use this feature. A such feature is only useful when pass-through a device to the guest on platfom without SMMU, so it is by default insecure. So I would suggest to create a new device-tree binding (or re-use an actual one) to reserve memory region to be used for direct memory mapped domain. Those regions could have an identifier to be used later during the allocation. This would avoid memory fragmentation, allow multiple RAM bank for DOM0,... Any opinions? Case 1: Dom0 is driver domain: There is a Ducati firmware which runs on dedicated M4 core and decodes video. This firmware uses hardcoded physical addresses for graphics buffers. Those addresses should be inside address-space of the driver domain (Dom0). Ducati firmware is proprietary and we have no ability to rework it. So Dom0 kernel should be placed to the configured address (to the DOM0 RAM bank with specific address). Case 2: Dom0 is Thin and DomD is driver domain. All is the same: Ducati firmware requires special (hardcoded) addresses. So if I understand correctly, patches #4, #13, #16 are only here to workaround a firmware which does not do the right thing? IHMO, modifying the memory allocator in Xen to make a firmware happy is just overkill. We need to explore all the possible solutions before going forward. From your description, it looks like to me that the device-tree does not correctly describe the platform. The graphic buffers should be reserved using /memreserve or via a specific binding. This would be used later by Xen to map the buffer into dom0 or allow dom0 to map it to a guest. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 3/6] libxl: implementation of PV tty device interface.
PV tty device interface is implemented in libxl and xl with
full support for device control. No JSON parser for domain
configuration yet.
Signed-off-by: Iurii Mykhalskyi
Signed-off-by: Iurii Konovalenko
---
tools/libxl/libxl.c | 282 +++
tools/libxl/libxl.h | 17 +++
tools/libxl/libxl_create.c | 37 -
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 13 +-
tools/libxl/libxl_types.idl | 19 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 3 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 160 +++-
tools/libxl/xl_cmdtable.c| 15 ++
11 files changed, 549 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d96172d..1426bf6 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2595,6 +2595,276 @@ exit:
/**/
+int libxl__device_vtty_setdefault(libxl__gc *gc, libxl_device_vtty *vtty)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vtty->backend_domname, &vtty->backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vtty(libxl__gc *gc, uint32_t domid,
libxl_device_vtty *vtty, libxl__device *device)
+{
+ device->backend_devid = vtty->devid;
+ device->backend_domid = vtty->backend_domid;
+ device->backend_kind= LIBXL__DEVICE_KIND_VTTY;
+ device->devid = vtty->devid;
+ device->domid = domid;
+ device->kind= LIBXL__DEVICE_KIND_VTTY;
+
+ return 0;
+}
+
+static int libxl__device_vtty_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vtty *vtty)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vtty_init(vtty);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+ vtty->devid = atoi(tmp);
+else
+ vtty->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vtty(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vtty *vtty)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vtty_init(vtty);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vtty/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vtty_from_xs_be(gc, path, vtty);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vtty_add(libxl__egc *egc, uint32_t domid, libxl_device_vtty
*vtty, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vtty vtty_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vtty_init(&vtty_saved);
+libxl_device_vtty_copy(CTX, &vtty_saved, vtty);
+
+rc = libxl__device_vtty_setdefault(gc, vtty);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vtty->devid = libxl__device_nextid(gc, domid, "vtty")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vtty(gc, domid, vtty, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vtty->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vtty->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vtty->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vtty->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+
+if (aodev->update_json) {
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
+}
+
+rc = libxl__get_domain_configuration(gc, domid, &d_config);
+LOG(INFO, "aodev updates JSON, libxl__get_domain_configuration
returned %d", rc);
+if (rc) goto out;
+
+DEVICE_ADD(vtty, vttys, domid, &vtty_saved, COMPARE_DEVID, &d_config);
+}
+
+for (;;) {
+rc = libxl__xs_transactio
[Xen-devel] [PATCH RFC 2/6] libxl: implementation of PV audio device interface
From: Pavlo Suikov
PV Audio device interface is implemented in libxl and xl with
full support for device control
Signed-off-by: Pavlo Suikov
Signed-off-by: Glib Golubytskyi
Signed-off-by: Iurii Konovalenko
---
tools/libxl/libxl.c | 351 ++-
tools/libxl/libxl.h | 16 ++
tools/libxl/libxl_create.c | 39 +++-
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.c | 4 +
tools/libxl/libxl_internal.h | 20 +-
tools/libxl/libxl_types.idl | 32
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 3 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 229 ++-
tools/libxl/xl_cmdtable.c| 20 ++
12 files changed, 715 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 09c4bc7..d96172d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2593,7 +2593,344 @@ exit:
return rc;
}
+/**/
+
+int libxl__device_vsnd_setdefault(libxl__gc *gc, libxl_device_vsnd *vsnd)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vsnd->backend_domname, &vsnd->backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vsnd(libxl__gc *gc, uint32_t domid,
libxl_device_vsnd *vsnd, libxl__device *device)
+{
+ device->backend_devid = vsnd->devid;
+ device->backend_domid = vsnd->backend_domid;
+ device->backend_kind= LIBXL__DEVICE_KIND_VSND;
+ device->devid = vsnd->devid;
+ device->domid = domid;
+ device->kind= LIBXL__DEVICE_KIND_VSND;
+
+ return 0;
+}
+
+static int libxl__device_vsnd_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vsnd *vsnd)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vsnd_init(vsnd);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vsnd->devid = atoi(tmp);
+else
+vsnd->devid = 0;
+
+vsnd->short_name = READ_BACKEND(gc, "short-name");
+vsnd->long_name = READ_BACKEND(gc, "long-name");
+vsnd->sample_formats = READ_BACKEND(gc, "sample-formats");
+vsnd->rates = READ_BACKEND(gc, "rates");
+
+tmp = READ_BACKEND(gc, "channels-min");
+if (tmp)
+vsnd->channels_min = atoi(tmp);
+else
+vsnd->channels_min = 0;
+
+tmp = READ_BACKEND(gc, "channels-max");
+if (tmp)
+vsnd->channels_max = atoi(tmp);
+else
+vsnd->channels_max = 0;
+
+tmp = READ_BACKEND(gc, "priority");
+if (tmp)
+vsnd->priority = atoi(tmp);
+else
+vsnd->priority = 0;
+
+vsnd->slave_device = READ_BACKEND(gc, "slave-device");
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vsnd(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vsnd *vsnd)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vsnd_init(vsnd);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vsnd/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vsnd_from_xs_be(gc, path, vsnd);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+
+void libxl__device_vsnd_add(libxl__egc *egc, uint32_t domid, libxl_device_vsnd
*vsnd, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vsnd vsnd_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vsnd_init(&vsnd_saved);
+libxl_device_vsnd_copy(CTX, &vsnd_saved, vsnd);
+
+rc = libxl__device_vsnd_setdefault(gc, vsnd);
+if (rc) goto out;
+
+front = flexarray_make(gc, 32, 1);
+back = flexarray_make(gc, 32, 1);
+if (vsnd->devid == -1) {
+if ((vsnd->devid = libxl__device_nextid(gc, domid, "vsnd")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+}
+
+libxl__update_config_vsnd(gc, &vsnd_saved, vsnd);
+
+GCNEW(device);
+rc = libxl__device_from_vsnd(gc, domid, vsnd, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "DomD");
+flexarray_append(back, "1");
+flexarray_append(back, "DomU");
+flexarray_append(back, "2");
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vsnd->devid));
+flexarray_append(back, "short-name");
+flexarray_append(back, vsnd->short_name);
+flexarray_append(back, "long
Re: [Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc
On Thu, May 19, 2016 at 03:29:45PM +0100, Andrew Cooper wrote:
> Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded \n in
> the signature checking paragraph.
>
> /usr/bin/pandoc --number-sections --toc --standalone misc/xsplice.markdown
> --output pdf/misc/xsplice.pdf
> ! Undefined control sequence.
> l.1085 appended\textasciitilde{}\n
>
> Surround the string in backticks to make it verbatim text.
Ok, where is that change?
>
> While altering this file, strip the substantial quantity of trailing
> whitespace.
Please do not. That was added specifically there otherwise
markdown messes it up when doing HTML and the lines get mangled up.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Ian Jackson
> CC: Wei Liu
> CC: Konrad Rzeszutek Wilk
> ---
> docs/misc/xsplice.markdown | 304
> ++---
> 1 file changed, 152 insertions(+), 152 deletions(-)
>
> diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
> index 4a98be1..80f8bc7 100644
> --- a/docs/misc/xsplice.markdown
> +++ b/docs/misc/xsplice.markdown
> @@ -90,18 +90,18 @@ As example we will assume the hypervisor does not have
> XSA-132 (see
> the hypervisor with it. The original code looks as so:
>
>
> - 48 89 e0 mov%rsp,%rax
> - 48 25 00 80 ff ff and$0x8000,%rax
> + 48 89 e0 mov%rsp,%rax
> + 48 25 00 80 ff ff and$0x8000,%rax
>
>
> while the new patched hypervisor would be:
>
>
> - 48 c7 45 b8 00 00 00 00 movq $0x0,-0x48(%rbp)
> - 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
> - 48 c7 45 c8 00 00 00 00 movq $0x0,-0x38(%rbp)
> - 48 89 e0 mov%rsp,%rax
> - 48 25 00 80 ff ff and$0x8000,%rax
> + 48 c7 45 b8 00 00 00 00 movq $0x0,-0x48(%rbp)
> + 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
> + 48 c7 45 c8 00 00 00 00 movq $0x0,-0x38(%rbp)
> + 48 89 e0 mov%rsp,%rax
> + 48 25 00 80 ff ff and$0x8000,%rax
>
>
> This is inside the arch_do_domctl. This new change adds 21 extra
> @@ -113,8 +113,8 @@ As such we could simplify this problem by only patching
> the site
> which calls arch_do_domctl:
>
>
> -do_domctl:
> - e8 4b b1 05 00 callq 82d08015fbb9
> +do_domctl:
> + e8 4b b1 05 00 callq 82d08015fbb9
>
>
> with a new address for where the new `arch_do_domctl` would be (this
> @@ -128,8 +128,8 @@ Patching the offset in `hypercall_table` for `do_domctl:
>
>
>
> - 82d08024d490: 79 30
> - 82d08024d492: 10 80 d0 82 ff ff
> + 82d08024d490: 79 30
> + 82d08024d492: 10 80 d0 82 ff ff
>
>
>
> @@ -172,9 +172,9 @@ from that). Patching the offset in `hypercall_table` for
> the old
> `do_xen_version` (82d080112f9e )
>
>
> - 82d08024b270 :
> - ...
> - 82d08024b2f8: 9e 2f 11 80 d0 82 ff ff
> + 82d08024b270 :
> + ...
> + 82d08024b2f8: 9e 2f 11 80 d0 82 ff ff
>
>
>
> @@ -187,17 +187,17 @@ An alternative solution would be to patch insert a
> trampoline in the
> old `do_xen_version' function to directly jump to the new `do_xen_version`.
>
>
> - 82d080112f9e do_xen_version:
> - 82d080112f9e: 48 c7 c0 da ff ff ffmov
> $0xffda,%rax
> - 82d080112fa5: 83 ff 09cmp$0x9,%edi
> - 82d080112fa8: 0f 87 24 05 00 00 ja 82d0801134d2 ;
> do_xen_version+0x534
> + 82d080112f9e do_xen_version:
> + 82d080112f9e: 48 c7 c0 da ff ff ffmov
> $0xffda,%rax
> + 82d080112fa5: 83 ff 09cmp$0x9,%edi
> + 82d080112fa8: 0f 87 24 05 00 00 ja 82d0801134d2 ;
> do_xen_version+0x534
>
>
> with:
>
>
> - 82d080112f9e do_xen_version:
> - 82d080112f9e: e9 XX YY ZZ QQ jmpq [new do_xen_version]
>
> + 82d080112f9e do_xen_version:
> + 82d080112f9e: e9 XX YY ZZ QQ jmpq [new do_xen_version]
>
>
> which would lessen the amount of patching to just one location.
> @@ -296,15 +296,15 @@ The `.xsplice.funcs` contains an array of
> xsplice_patch_func structures
> which describe the functions to be patched:
>
>
> -struct xsplice_patch_func {
> -const char *name;
> -void *new_addr;
> -void *old_addr;
> -uint32_t new_size;
> -uint32_t old_size;
> -uint8_t version;
> -uint8_t opaque[31];
> -};
> +struct xsplice_patch_func {
> +const char *name;
> +void *new_addr;
> +void *old_addr;
> +uint32_t new_size;
> +uint32_t old_size;
> +uint8_t version;
> +uint8_t opaque[31];
> +};
>
>
> The size of the structure is 64 bytes on 64-bit hypervisors. It will be
> @@ -345,33 +345,33 @@ to `old_addr`.
> A simple example of what a payload file ca
[Xen-devel] [PATCH RFC 0/6] Set of PV drivers used by production project
This patches introduce set of pv drivers interfaces. Drivers interfaces list: - PV RTC - real-time clock - PV TTY - interface for pv version for device controlled by via tty (e.g. GPS) - PV Audio - sound interface virtualization - PV DRM - direct rengering manager virtualization - PV RPMSG - remove procedure call interface, in our case used for playback codecs virtualization Iurii Mykhalskyi (2): libxl: implementation of PV rtc device interface libxl: implementation of PV tty device interface. Pavlo Suikov (4): libxl: implementation of PV audio device interface libxl: implementation of PV event device interface libxl: implementation of PV DRM device interface libxl: implementation of PV RPMSG device interface tools/libxl/libxl.c | 1781 +- tools/libxl/libxl.h | 102 ++ tools/libxl/libxl_create.c | 214 +++- tools/libxl/libxl_device.c | 12 + tools/libxl/libxl_internal.c |8 + tools/libxl/libxl_internal.h | 88 +- tools/libxl/libxl_types.idl | 131 +++ tools/libxl/libxl_types_internal.idl |6 + tools/libxl/libxl_utils.h| 19 + tools/libxl/xl.h | 18 + tools/libxl/xl_cmdimpl.c | 1035 +++- tools/libxl/xl_cmdtable.c| 95 ++ 12 files changed, 3499 insertions(+), 10 deletions(-) -- 2.8.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 1/6] libxl: implementation of PV rtc device interface
PV rtc device interface is implemented in libxl and xl with
full support for device control. No JSON parser for domain
configuration yet.
Signed-off-by: Iurii Mykhalskyi
Signed-off-by: Glib Golubytskyi
Signed-off-by: Iurii Konovalenko
---
tools/libxl/libxl.c | 287 ++-
tools/libxl/libxl.h | 17 +++
tools/libxl/libxl_create.c | 39 -
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 19 ++-
tools/libxl/libxl_types.idl | 19 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 3 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 161 +++-
tools/libxl/xl_cmdtable.c| 15 ++
11 files changed, 558 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ac50bda..09c4bc7 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2323,6 +2323,277 @@ int libxl_devid_to_device_vtpm(libxl_ctx *ctx,
return rc;
}
+/**/
+
+int libxl__device_vrtc_setdefault(libxl__gc *gc, libxl_device_vrtc *vrtc)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vrtc->backend_domname, &vrtc->backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vrtc(libxl__gc *gc, uint32_t domid,
libxl_device_vrtc *vrtc, libxl__device *device)
+{
+ device->backend_devid = vrtc->devid;
+ device->backend_domid = vrtc->backend_domid;
+ device->backend_kind= LIBXL__DEVICE_KIND_VRTC;
+ device->devid = vrtc->devid;
+ device->domid = domid;
+ device->kind= LIBXL__DEVICE_KIND_VRTC;
+
+ return 0;
+}
+
+static int libxl__device_vrtc_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vrtc *vrtc)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vrtc_init(vrtc);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vrtc->devid = atoi(tmp);
+else
+vrtc->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vrtc(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vrtc *vrtc)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vrtc_init(vrtc);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vrtc/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vrtc_from_xs_be(gc, path, vrtc);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vrtc_add(libxl__egc *egc, uint32_t domid, libxl_device_vrtc
*vrtc, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vrtc vrtc_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vrtc_init(&vrtc_saved);
+libxl_device_vrtc_copy(CTX, &vrtc_saved, vrtc);
+
+rc = libxl__device_vrtc_setdefault(gc, vrtc);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vrtc->devid = libxl__device_nextid(gc, domid, "vrtc")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vrtc(gc, domid, vrtc, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vrtc->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vrtc->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vrtc->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vrtc->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+
+if (aodev->update_json) {
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
+}
+
+rc = libxl__get_domain_configuration(gc, domid, &d_config);
+LOG(INFO, "aodev updates JSON, libxl__get_domain_configuration
returned %d", rc);
+if (rc) goto out;
+
+DEVICE_ADD(vrtc, vrtcs, domid, &vrt
[Xen-devel] [PATCH RFC 4/6] libxl: implementation of PV event device interface
From: Pavlo Suikov
Touchscreen events device configuration support. Can be further
extended to support any event device whatsoever.
Signed-off-by: Pavlo Suikov
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
---
tools/libxl/libxl.c | 289 ++-
tools/libxl/libxl.h | 17 +++
tools/libxl/libxl_create.c | 39 -
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.c | 4 +
tools/libxl/libxl_internal.h | 20 ++-
tools/libxl/libxl_types.idl | 21 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 4 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 170 -
tools/libxl/xl_cmdtable.c| 15 ++
12 files changed, 580 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1426bf6..b64815e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5003,6 +5003,282 @@ out:
/**/
+int libxl__device_vevent_setdefault(libxl__gc *gc, libxl_device_vevent *vevent)
+{
+int rc;
+rc = libxl__resolve_domid(gc, vevent->backend_domname,
&vevent->backend_domid);
+return rc;
+}
+
+static int libxl__device_from_vevent(libxl__gc *gc, uint32_t domid,
+ libxl_device_vevent *vevent,
+ libxl__device *device)
+{
+device->backend_devid = vevent->devid;
+device->backend_domid = vevent->backend_domid;
+device->backend_kind = LIBXL__DEVICE_KIND_VEVENT;
+device->devid = vevent->devid;
+device->domid = domid;
+device->kind = LIBXL__DEVICE_KIND_VEVENT;
+
+return 0;
+}
+
+static int libxl__device_vevent_from_xs_be(libxl__gc *gc,
+ const char *be_path,
+ libxl_device_vevent *vevent)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vevent_init(vevent);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vevent->devid = atoi(tmp);
+else
+vevent->devid = 0;
+
+rc = 0;
+out:
+return rc;
+}
+
+int libxl_devid_to_device_vevent(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vevent *vevent)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vevent_init(vevent);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vevent/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vevent_from_xs_be(gc, path, vevent);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vevent_add(libxl__egc *egc, uint32_t domid,
+ libxl_device_vevent *vevent,
+ libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vevent vevent_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vevent_init(&vevent_saved);
+libxl_device_vevent_copy(CTX, &vevent_saved, vevent);
+
+rc = libxl__device_vevent_setdefault(gc, vevent);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 16, 1);
+if (vevent->devid == -1) {
+if ((vevent->devid = libxl__device_nextid(gc, domid, "vevent")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+}
+
+libxl__update_config_vevent(gc, &vevent_saved, vevent);
+
+GCNEW(device);
+rc = libxl__device_from_vevent(gc, domid, vevent, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "feature-abs-pointer");
+flexarray_append(back, libxl__sprintf(gc, "%d",
vevent->feature_abs_pointer));
+flexarray_append(back, "abs-width");
+flexarray_append(back, libxl__sprintf(gc, "%d", vevent->abs_width));
+flexarray_append(back, "abs-height");
+flexarray_append(back, libxl__sprintf(gc, "%d", vevent->abs_height));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vevent->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, libxl__sprintf(gc, "%d", vevent->backend_do
[Xen-devel] [PATCH RFC 6/6] libxl: implementation of PV RPMSG device interface
From: Pavlo Suikov
Signed-off-by: Pavlo Suikov
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
---
tools/libxl/libxl.c | 282 +++
tools/libxl/libxl.h | 17 +++
tools/libxl/libxl_create.c | 40 -
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 13 +-
tools/libxl/libxl_types.idl | 19 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 3 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 161 +++-
tools/libxl/xl_cmdtable.c| 21 ++-
11 files changed, 554 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ccb0411..871061d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2873,6 +2873,276 @@ exit:
/**/
+int libxl__device_vrpmsg_setdefault(libxl__gc *gc, libxl_device_vrpmsg *vrpmsg)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vrpmsg->backend_domname,
&vrpmsg->backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vrpmsg(libxl__gc *gc, uint32_t domid,
libxl_device_vrpmsg *vrpmsg, libxl__device *device)
+{
+ device->backend_devid = vrpmsg->devid;
+ device->backend_domid = vrpmsg->backend_domid;
+ device->backend_kind= LIBXL__DEVICE_KIND_VRPMSG;
+ device->devid = vrpmsg->devid;
+ device->domid = domid;
+ device->kind= LIBXL__DEVICE_KIND_VRPMSG;
+
+ return 0;
+}
+
+static int libxl__device_vrpmsg_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vrpmsg *vrpmsg)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vrpmsg_init(vrpmsg);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vrpmsg->devid = atoi(tmp);
+else
+vrpmsg->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vrpmsg(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vrpmsg *vrpmsg)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vrpmsg_init(vrpmsg);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vrpmsg/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vrpmsg_from_xs_be(gc, path, vrpmsg);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vrpmsg_add(libxl__egc *egc, uint32_t domid,
libxl_device_vrpmsg *vrpmsg, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vrpmsg vrpmsg_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vrpmsg_init(&vrpmsg_saved);
+libxl_device_vrpmsg_copy(CTX, &vrpmsg_saved, vrpmsg);
+
+rc = libxl__device_vrpmsg_setdefault(gc, vrpmsg);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vrpmsg->devid = libxl__device_nextid(gc, domid, "vrpmsg")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vrpmsg(gc, domid, vrpmsg, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vrpmsg->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vrpmsg->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vrpmsg->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vrpmsg->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+
+if (aodev->update_json) {
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
+}
+
+rc = libxl__get_domain_configuration(gc, domid, &d_config);
+LOG(INFO, "aodev updates JSON, libxl__get_domain_configuration
returned %d", rc);
+if (rc) goto out;
+
+DEVICE_ADD(vrpmsg, vrpmsgs, domid, &vrpmsg_saved, COMPARE_DEVID,
&d_config);
+}
+
+for (;;) {
+rc = li
[Xen-devel] [PATCH RFC 5/6] libxl: implementation of PV DRM device interface
From: Pavlo Suikov
Signed-off-by: Pavlo Suikov
Signed-off-by: Glib Golubytskyi
Signed-off-by: Iurii Konovalenko
Signed-off-by: Iurii Mykhalskyi
---
tools/libxl/libxl.c | 290 +++
tools/libxl/libxl.h | 18 +++
tools/libxl/libxl_create.c | 42 -
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 13 +-
tools/libxl/libxl_types.idl | 21 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_utils.h| 3 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 164 +++-
tools/libxl/xl_cmdtable.c| 15 ++
11 files changed, 567 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b64815e..ccb0411 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2595,6 +2595,284 @@ exit:
/**/
+int libxl__device_vdrm_setdefault(libxl__gc *gc, libxl_device_vdrm *vdrm)
+{
+int rc;
+
+rc = libxl__resolve_domid(gc, vdrm->backend_domname, &vdrm->backend_domid);
+
+return rc;
+}
+
+static int libxl__device_from_vdrm(libxl__gc *gc, uint32_t domid,
libxl_device_vdrm *vdrm, libxl__device *device)
+{
+ device->backend_devid = vdrm->devid;
+ device->backend_domid = vdrm->backend_domid;
+ device->backend_kind= LIBXL__DEVICE_KIND_VDRM;
+ device->devid = vdrm->devid;
+ device->domid = domid;
+ device->kind= LIBXL__DEVICE_KIND_VDRM;
+
+ return 0;
+}
+
+static int libxl__device_vdrm_from_xs_be(libxl__gc *gc,
+const char *be_path,
+libxl_device_vdrm *vdrm)
+{
+const char *tmp;
+int rc;
+
+libxl_device_vdrm_init(vdrm);
+
+tmp = READ_BACKEND(gc, "device-id");
+if (tmp)
+vdrm->devid = atoi(tmp);
+else
+vdrm->devid = 0;
+
+rc = 0;
+ out:
+return rc;
+}
+
+int libxl_devid_to_device_vdrm(libxl_ctx *ctx, uint32_t domid,
+ int devid, libxl_device_vdrm *vdrm)
+{
+GC_INIT(ctx);
+char *dompath, *path;
+int rc = ERROR_FAIL;
+
+libxl_device_vdrm_init(vdrm);
+dompath = libxl__xs_get_dompath(gc, domid);
+if (!dompath)
+goto out;
+
+path = libxl__xs_read(gc, XBT_NULL,
+ libxl__sprintf(gc, "%s/device/vdrm/%d/backend",
+ dompath, devid));
+if (!path)
+goto out;
+
+rc = libxl__device_vdrm_from_xs_be(gc, path, vdrm);
+if (rc) goto out;
+
+rc = 0;
+out:
+GC_FREE;
+return rc;
+}
+
+void libxl__device_vdrm_add(libxl__egc *egc, uint32_t domid, libxl_device_vdrm
*vdrm, libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev->ao);
+flexarray_t *front;
+flexarray_t *back;
+libxl__device *device;
+int rc;
+xs_transaction_t t = XBT_NULL;
+libxl_domain_config d_config;
+libxl_device_vdrm vdrm_saved;
+libxl__domain_userdata_lock *lock = NULL;
+
+libxl_domain_config_init(&d_config);
+libxl_device_vdrm_init(&vdrm_saved);
+libxl_device_vdrm_copy(CTX, &vdrm_saved, vdrm);
+
+rc = libxl__device_vdrm_setdefault(gc, vdrm);
+if (rc) goto out;
+
+front = flexarray_make(gc, 16, 1);
+back = flexarray_make(gc, 32, 1);
+
+if ((vdrm->devid = libxl__device_nextid(gc, domid, "vdrm")) < 0) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+GCNEW(device);
+rc = libxl__device_from_vdrm(gc, domid, vdrm, device);
+if ( rc != 0 ) goto out;
+
+flexarray_append(back, "device-id");
+flexarray_append(back, GCSPRINTF("%d", vdrm->devid));
+flexarray_append(back, "frontend-id");
+flexarray_append(back, GCSPRINTF("%d", domid));
+flexarray_append(back, "device");
+flexarray_append(back, vdrm->device);
+flexarray_append(back, "online");
+flexarray_append(back, "1");
+flexarray_append(back, "state");
+flexarray_append(back, GCSPRINTF("%d", 1));
+flexarray_append(back, "mode0");
+flexarray_append(back, vdrm->mode0);
+flexarray_append(back, "mode1");
+flexarray_append(back, vdrm->mode1);
+
+flexarray_append(front, "device-id");
+flexarray_append(front, GCSPRINTF("%d", vdrm->devid));
+flexarray_append(front, "backend-id");
+flexarray_append(front, GCSPRINTF("%d", vdrm->backend_domid));
+flexarray_append(front, "state");
+flexarray_append(front, GCSPRINTF("%d", 1));
+flexarray_append(front, "mode0");
+flexarray_append(front, vdrm->mode0);
+flexarray_append(front, "mode1");
+flexarray_append(front, vdrm->mode1);
+
+if (aodev->update_json) {
+lock = libxl__lock_domain_userdata(gc, domid);
+if (!lock) {
+rc = ERROR_LOCK_FAIL;
+goto out;
+}
+
+rc = libxl__get_domain_configuration(gc, domid, &d
Re: [Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc
On 19/05/16 15:36, Konrad Rzeszutek Wilk wrote:
> On Thu, May 19, 2016 at 03:29:45PM +0100, Andrew Cooper wrote:
>> Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded \n in
>> the signature checking paragraph.
>>
>> /usr/bin/pandoc --number-sections --toc --standalone misc/xsplice.markdown
>> --output pdf/misc/xsplice.pdf
>> ! Undefined control sequence.
>> l.1085 appended\textasciitilde{}\n
>>
>> Surround the string in backticks to make it verbatim text.
> Ok, where is that change?
> @@ -1007,46 +1007,46 @@ expecting such that it can properly do signature
> verification.
>
> The signature is based on the all of the payloads continuously laid out
> in memory. The signature is to be appended at the end of the ELF payload
> -prefixed with the string '~Module signature appended~\n', followed by
> +prefixed with the string `'~Module signature appended~\n'`, followed by
> an signature header then followed by the signature, key identifier, and
> signers
> name.
^ Here.
>> While altering this file, strip the substantial quantity of trailing
>> whitespace.
> Please do not. That was added specifically there otherwise
> markdown messes it up when doing HTML and the lines get mangled up.
Markdown isn't whitespace sensitive, so that really shouldn't be doing
anything. If you want a verbatim text block, indent it by 4 characters.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] when to bump library versions (was: )
>>> On 19.05.16 at 16:34, wrote: > Currently we bump the shared library names just before the release, so ATM > xen-unstable is still using the library names from the 4.6 release. This is > an issue if someone wants to install both Xen 4.6 and xen-unstable in the > same box (unless you use a different prefix/DESTDIR), because libraries from > xen-unstable will replace the stable ones. > > IMHO, it would make more sense to bump the library names just *after* we > branch and open the tree for development again. As you may have seen in Wei's recent commit, not all libraries have their versions bumped for a given release. > We could even have the > library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so > that we don't need to go around the different library makefiles bumping the > versions manually. But so far these two are intentionally private to the xen/ subtree. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.14 test] 94568: tolerable FAIL - PUSHED
flight 94568 linux-3.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/94568/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i386-rumpuserxen6 xen-buildfail like 94027 build-amd64-rumpuserxen 6 xen-buildfail like 94027 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94027 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 94027 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 94027 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linuxc977650a67e6ca6c3cff9548b031d072d00db80a baseline version: linux1c767107ef341cdc080d44d3ee1c9ca1b6957ce0 Last test of basis94027 2016-05-11 09:44:33 Z8 days Testing same since94568 2016-05-19 01:45:01 Z0 days1 attempts People who touched revisions under test: Al Viro Alex Deucher Allain Legacy Andi Kleen Ben Hutchings Chris Friesen Chris Wilson Daniel Vetter Daniel Vetter David S. Miller Dmitry Torokhov Greg Kroah-Hartman H. Peter Anvin Herbert Xu Ian Campbell Jani Nikula Kangjie Lu Kangjie Lu Kevin Hilman Krzysztof Kozlowski Lucas Stach Maarten Lankhorst Marek Szyprowski Mathias Krause Nikolay Aleksandrov Pavel Emelyanov Tony Lindgren jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass t
Re: [Xen-devel] [PATCH RFC 13/18] xen: introduce and use 'dom0_rambase_pfn' setting for kernel Dom0
>>> On 19.05.16 at 15:58, wrote: > Case 1: Dom0 is driver domain: > There is a Ducati firmware which runs on dedicated M4 core and decodes > video. This firmware uses hardcoded physical addresses for graphics > buffers. Those addresses should be inside address-space of the driver > domain (Dom0). Ducati firmware is proprietary and we have no ability > to rework it. So Dom0 kernel should be placed to the configured > address (to the DOM0 RAM bank with specific address). > > Case 2: Dom0 is Thin and DomD is driver domain. > All is the same: Ducati firmware requires special (hardcoded) addresses. For both of these cases I would then wonder whether such environments are actually suitable for doing virtualization on. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/HVM: fix forwarding of internally cached requests
On May 19, 2016 5:15 PM, Jan Beulich wrote: > >>> On 19.05.16 at 10:30, wrote: > > On April 28, 2016 11:13 PM, Jan Beulich wrote: > >> >>> On 25.04.16 at 10:40, wrote: > >> > With other patches also in place, still not work. > >> > Jianzhong has been left and Quan will take over the task. > >> > >> May I ask for another try, with current tip of staging plus > >> http://lists.xenproject.org/archives/html/xen-devel/2016- > >> 04/msg03661.html > >> ? > > > > The same issue for rhel 6.4VM, which cannot initialize VF driver > > too.. the below is log of rhel 6.4 VM: > > .. > > igbvf: :00.04.0: Invalid MAC Address: 00:00:00:00:00:00 > > igbvf: probe of :00.04.0 failed with error -5 > > .. > > > > But when I tried to initialize VF MAC in Dom0 with e.g.: > > $ip link set eth0 vf 0 mac 00:1E:67:65:93:01 > > Makes things even more strange, as things work fine for me with > SLE11 and SLE12 guests. But I have to admit that the "Invalid MAC Address" > looks quite unrelated, i.e. is this perhaps some completely different problem > you have? I tried to run SLE12 guest. Things are really working fine for me too.. But not for rhel 6.4 guest.. So far, I think the bug is not from xen hypervisor, just from vf driver. Look at this bug, even from KVM --- igb VF can't work in KVM guest, https://bugzilla.kernel.org/show_bug.cgi?id=55421 > > Again, considering that you have a repro (while I don't), the easiest would be > to simply log all MSI-X related actions (there shouldn't be too many), to see > where things go wrong. Such a log alone would maybe already allow me to do > further investigation. > I need more time to read this part, but sure I will follow it. Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Bump library names just after branching
Sorry, re-sending the message with a proper subject line: Hello, Currently we bump the shared library names just before the release, so ATM xen-unstable is still using the library names from the 4.6 release. This is an issue if someone wants to install both Xen 4.6 and xen-unstable in the same box (unless you use a different prefix/DESTDIR), because libraries from xen-unstable will replace the stable ones. IMHO, it would make more sense to bump the library names just *after* we branch and open the tree for development again. We could even have the library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so that we don't need to go around the different library makefiles bumping the versions manually. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] when to bump library versions (was: )
On Thu, May 19, 2016 at 08:44:59AM -0600, Jan Beulich wrote: > >>> On 19.05.16 at 16:34, wrote: > > Currently we bump the shared library names just before the release, so ATM > > xen-unstable is still using the library names from the 4.6 release. This is > > an issue if someone wants to install both Xen 4.6 and xen-unstable in the > > same box (unless you use a different prefix/DESTDIR), because libraries > > from > > xen-unstable will replace the stable ones. > > > > IMHO, it would make more sense to bump the library names just *after* we > > branch and open the tree for development again. > > As you may have seen in Wei's recent commit, not all libraries have > their versions bumped for a given release. IMHO, I would make them all bump, regardless of whether there have been changes or not. > > We could even have the > > library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so > > that we don't need to go around the different library makefiles bumping the > > versions manually. > > But so far these two are intentionally private to the xen/ subtree. Maybe I'm missing something, but couldn't they be global to the whole tree? (Config.mk seems like a suitable place). Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc
On Thu, May 19, 2016 at 03:41:49PM +0100, Andrew Cooper wrote:
> On 19/05/16 15:36, Konrad Rzeszutek Wilk wrote:
> > On Thu, May 19, 2016 at 03:29:45PM +0100, Andrew Cooper wrote:
> >> Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded \n
> >> in
> >> the signature checking paragraph.
> >>
> >> /usr/bin/pandoc --number-sections --toc --standalone
> >> misc/xsplice.markdown
> >> --output pdf/misc/xsplice.pdf
> >> ! Undefined control sequence.
> >> l.1085 appended\textasciitilde{}\n
> >>
> >> Surround the string in backticks to make it verbatim text.
> > Ok, where is that change?
>
> > @@ -1007,46 +1007,46 @@ expecting such that it can properly do signature
> > verification.
> >
> > The signature is based on the all of the payloads continuously laid out
> > in memory. The signature is to be appended at the end of the ELF payload
> > -prefixed with the string '~Module signature appended~\n', followed by
> > +prefixed with the string `'~Module signature appended~\n'`, followed by
> > an signature header then followed by the signature, key identifier, and
> > signers
> > name.
>
> ^ Here.
Thank you!
>
> >> While altering this file, strip the substantial quantity of trailing
> >> whitespace.
> > Please do not. That was added specifically there otherwise
> > markdown messes it up when doing HTML and the lines get mangled up.
>
> Markdown isn't whitespace sensitive, so that really shouldn't be doing
> anything. If you want a verbatim text block, indent it by 4 characters.
https://daringfireball.net/projects/markdown/syntax
"When you do want to insert a break tag using Markdown, you end a
line with two or more spaces, then type return."
But if this can be done with indenting it with 4 characters that would
work too.
>
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] when to bump library versions (was: )
>>> On 19.05.16 at 16:53, wrote: > On Thu, May 19, 2016 at 08:44:59AM -0600, Jan Beulich wrote: >> >>> On 19.05.16 at 16:34, wrote: >> > We could even have the >> > library name versions be set based on XEN_VERSION and XEN_SUBVERSION, so >> > that we don't need to go around the different library makefiles bumping >> > the >> > versions manually. >> >> But so far these two are intentionally private to the xen/ subtree. > > Maybe I'm missing something, but couldn't they be global to the whole tree? > (Config.mk seems like a suitable place). I think originally the idea was that the tool stack isn't really tied to a specific hypervisor version. What it is tied to is an interface version (of namely domctl and sysctl). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc
On 19/05/16 15:56, Konrad Rzeszutek Wilk wrote:
> On Thu, May 19, 2016 at 03:41:49PM +0100, Andrew Cooper wrote:
>> On 19/05/16 15:36, Konrad Rzeszutek Wilk wrote:
>>> On Thu, May 19, 2016 at 03:29:45PM +0100, Andrew Cooper wrote:
Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded \n
in
the signature checking paragraph.
/usr/bin/pandoc --number-sections --toc --standalone
misc/xsplice.markdown
--output pdf/misc/xsplice.pdf
! Undefined control sequence.
l.1085 appended\textasciitilde{}\n
Surround the string in backticks to make it verbatim text.
>>> Ok, where is that change?
>>> @@ -1007,46 +1007,46 @@ expecting such that it can properly do signature
>>> verification.
>>>
>>> The signature is based on the all of the payloads continuously laid out
>>> in memory. The signature is to be appended at the end of the ELF payload
>>> -prefixed with the string '~Module signature appended~\n', followed by
>>> +prefixed with the string `'~Module signature appended~\n'`, followed by
>>> an signature header then followed by the signature, key identifier, and
>>> signers
>>> name.
>> ^ Here.
> Thank you!
While altering this file, strip the substantial quantity of trailing
whitespace.
>>> Please do not. That was added specifically there otherwise
>>> markdown messes it up when doing HTML and the lines get mangled up.
>> Markdown isn't whitespace sensitive, so that really shouldn't be doing
>> anything. If you want a verbatim text block, indent it by 4 characters.
> https://daringfireball.net/projects/markdown/syntax
>
> "When you do want to insert a break tag using Markdown, you end a
> line with two or more spaces, then type return."
(You learn something every day), and eww... That is nasty.
>
> But if this can be done with indenting it with 4 characters that would
> work too.
I recommend https://daringfireball.net/projects/markdown/syntax#precode
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7 2/3] docs/xsplice: Fix syntax when compiling to pdf with pandoc
On Thu, May 19, 2016 at 10:56:06AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, May 19, 2016 at 03:41:49PM +0100, Andrew Cooper wrote:
> > On 19/05/16 15:36, Konrad Rzeszutek Wilk wrote:
> > > On Thu, May 19, 2016 at 03:29:45PM +0100, Andrew Cooper wrote:
> > >> Pandoc (version 1.12.4.2 from Debian Jessie) complains at the embedded
> > >> \n in
> > >> the signature checking paragraph.
> > >>
> > >> /usr/bin/pandoc --number-sections --toc --standalone
> > >> misc/xsplice.markdown
> > >> --output pdf/misc/xsplice.pdf
> > >> ! Undefined control sequence.
> > >> l.1085 appended\textasciitilde{}\n
> > >>
> > >> Surround the string in backticks to make it verbatim text.
> > > Ok, where is that change?
> >
> > > @@ -1007,46 +1007,46 @@ expecting such that it can properly do signature
> > > verification.
> > >
> > > The signature is based on the all of the payloads continuously laid out
> > > in memory. The signature is to be appended at the end of the ELF payload
> > > -prefixed with the string '~Module signature appended~\n', followed by
> > > +prefixed with the string `'~Module signature appended~\n'`, followed by
> > > an signature header then followed by the signature, key identifier, and
> > > signers
> > > name.
> >
> > ^ Here.
>
> Thank you!
> >
> > >> While altering this file, strip the substantial quantity of trailing
> > >> whitespace.
> > > Please do not. That was added specifically there otherwise
> > > markdown messes it up when doing HTML and the lines get mangled up.
> >
> > Markdown isn't whitespace sensitive, so that really shouldn't be doing
> > anything. If you want a verbatim text block, indent it by 4 characters.
>
> https://daringfireball.net/projects/markdown/syntax
>
> "When you do want to insert a break tag using Markdown, you end a
> line with two or more spaces, then type return."
>
> But if this can be done with indenting it with 4 characters that would
> work too.
>
I take it you're happy with this change? Do you want to test it and
report back?
Wei.
> >
> > ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation
On May 19, 2016 7:36 PM, Jan Beulich wrote: > >>> On 19.05.16 at 13:26, wrote: > > On May 19, 2016 2:13 PM, Jan Beulich wrote: > >> >>> "Xu, Quan" 05/19/16 3:35 AM >>> > >> >On May 19, 2016 8:33 AM, Tian, Kevin wrote: > >> >> A single default value for both IOMMU-side and device-side is > >> >> anyway not optimal. What about introducing a new knob e.g. > >> >> vtd_qi_device_timeout specifically for device-side flush while > >> >> using vtd_qi_timeout for other places? If device-side timeout is > >> >> not specified, it is > >> then default to vtd_qi_timeout. > >> > >> There should imo be a single command line option, allowing for two > >> values to be passed (e.g. comma-separated). > > > > As mentioned, 1 ms is enough for VT-d IOTLB/Context/IEC invalidation, > > so we are no need to increasing the value of timeout or introduce a > > boot-time changed parameter. > > What about a constant (e.g. a macro), 1 ms, for VT-d IOTLB/Context/IEC > > invalidation timeout. > > If you're absolutely certain no-one will ever find a need to increase that > value - > sure. > Sure. Also this was mentioned in Kevin's ' Revisit VT-d asynchronous flush issue ' , http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00041.html """-For context/iotlb/iec flush, our measurements show worst cases <10us. We also confirmed with hardware team, that 1ms is large enough for IOMMU internal flush. """ > > For Device-TLB invalidation, we can introduce 'vtd_qi_device_timeout', > > which is boot-time changed, and 1 ms by default. > > One question is whether making this a VT-d specific command line option is a > good idea: Other IOMMU implementations ought to be in need of doing > device IOTLB invalidation too, at least sooner or later. > This is indeed farsighted. Agreed. > The other question is whether any timeout lower than the current one can be > considered safe (and hence is usable as a default). > Actually the criticality, 1 ms, is from hardware team. IOW, Our hardware team confirmed that 1ms should be enough for integrated PCI devices with ATS. for discrete PCI devices with ATS, it's uncertain whether 1ms or 10ms is too restrictive to them, but there are only a few devices now in the market. Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: sched: avoid races on time values read from NOW()
On Thu, May 19, 2016 at 4:11 AM, Dario Faggioli wrote: > or (even in cases where there is no race, e.g., outside > of Credit2) avoid using a time sample which may be rather > old, and hence stale. > > In fact, we should only sample NOW() from _inside_ > the critical region within which the value we read is > used. If we don't, in case we have to spin for a while > before entering the region, when actually using it: > > 1) we will use something that, at the veryy least, is > not really "now", because of the spinning, > > 2) if someone else sampled NOW() during a critical > region protected by the lock we are spinning on, > and if we compare the two samples when we get > inside our region, our one will be 'earlier', > even if we actually arrived later, which is a > race. > > In Credit2, we see an instance of 2), in runq_tickle(), > when it is called by csched2_context_saved() as it samples > NOW() before acquiring the runq lock. This makes things > look like the time went backwards, and it confuses the > algorithm (there's even a d2printk() about it, which would > trigger all the time, if enabled). > > In RTDS, something similar happens in repl_timer_handler(), > and there's another instance in schedule() (in generic code), > so fix these cases too. > > While there, improve csched2_vcpu_wake() and and rt_vcpu_wake() > a little as well (removing a pointless initialization, and > moving the sampling a bit closer to its use). These two hunks > entail no further functional changes. > > Signed-off-by: Dario Faggioli > --- > Cc: George Dunlap > Cc: Meng Xu > Cc: Wei Liu > --- Reviewed-by: Meng Xu The bug will cause incorrect budget accounting for one VCPU when the race occurs. Best Regards, Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.7] xen: sched: avoid races on time values read from NOW()
On Thu, May 19, 2016 at 4:11 AM, Dario Faggioli wrote: > Hey Wei, > > Again, I'm using an otherwise unnecessary cover letter for my analysis about > <>. :-) > > I'd say yes, because the patch fixes an actual bug, in the form of a rather > subtle race condition, which was all but trivial to spot. I must say, though, > that I've only found the bug guilty of being particularly nasty if we use > Credit2. Actually, I'm quite sure it has an effect on RTDS too (although I > did > not trace that), but since both Credit2 and RTDS are still marked as > experimental in 4.7, one may think it's not worthwhile putting in something > like this to fix experimental only code. > > Just FYI, this bug is what was causing the issue I briefly chatted about on > IRC > with George, yesterday, i.e., it is what led Credit2 to emit (rather > aggresively, actually) the debug printks showed here: > > http://pastebin.com/gzYrNST5 In addition to the race condition in the bare metal, actually I saw this when I debug/run Xen in VirtualBox. The situation is: If we have nested virtualization or if we have heterogeneous cores which have different speed/time, the RTDS scheduler (maybe credit2 as well?) will have a problem in budget accounting. The "CPU" of Xen is scheduled by the underlining hypervisor. One "CPU" of Xen could be slower than another, showing the time is left behind. We explicitly say that RTDS will have incorrect budget accounting for nested virtualization situation, when the RTDS was upstreamed in Xen 4.5. Best Regards, Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 94582: tolerable all pass - PUSHED
flight 94582 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94582/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen a396c2549e079ab2f644aab8b2e7f47a8d0e3937
baseline version:
xen 2bb230972c5ddb1ca823f47750b5d46a9d302d0e
Last test of basis94579 2016-05-19 11:01:49 Z0 days
Testing same since94582 2016-05-19 14:03:32 Z0 days1 attempts
People who touched revisions under test:
Dario Faggioli
George Dunlap
Ian Jackson
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=a396c2549e079ab2f644aab8b2e7f47a8d0e3937
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
a396c2549e079ab2f644aab8b2e7f47a8d0e3937
+ branch=xen-unstable-smoke
+ revision=a396c2549e079ab2f644aab8b2e7f47a8d0e3937
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xa396c2549e079ab2f644aab8b2e7f47a8d0e3937 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x '
