Re: [Xen-devel] (XEN) APIC error on CPU0: 40(00)
>>> On 04.11.15 at 22:09, wrote: > On 04/11/2015 17:13, Jan Beulich wrote: > On 04.11.15 at 16:15, wrote: >>> Hi, >>> i just build the latest 4.3.0 kernel and ran it on qubes-os with xen >>> 4.4.3. I get this error just before the reboot: >>> >>> [(XEN) APIC error on CPU0: 40(00) >> >> And this appeared with the switch to kernel 4.3? No other variable >> (e.g. all config options new in 4.3 turned off)? I ask because the >> APIC is driven by Xen, not the kernel, and hence the kernel should >> have no (direct) influence on APIC behavior. > > This started with 4.3.0, with 4.3.0-rc7 the system was booting properly > (except for the xsave=0 workaround, without that i also get a crash dump > right before the APIC error). Now that's a pretty narrow window. I just looked at the source diff, without spotting anything even just remotely suspicious. Such a narrow window would of course allow for relatively quick and simple bisection... Just to ask the unanswered part of the previous question again: There were _no_ other changes to the system? I.e. if you go back to -rc7 now, you don't see the problem anymore? >>> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. I'm not aware of a code path leading here without any other Xen messages, and without the reboot having been initiated by Dom0. >>> My machine runs on skylake cpu with z170 chipset and the latest bios. >>> Any ideas on how to fix this? >> >> Not without first figuring out what bad vector is being received >> by the APIC, which likely will involved quite a bit of debugging >> and code instrumentation. > > Do you think that this could be caused by some sort of hardware/firmware > issue? Unlikely, but not entirely impossible. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Revisit VT-d asynchronous flush issue
> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Tuesday, November 03, 2015 6:04 PM > > >>> On 03.11.15 at 10:58, wrote: > > On 02/11/15 14:10, Jan Beulich wrote: > > On 02.11.15 at 09:03, wrote: > >>> Based on above information, we propose to continue spin-timeout > >>> model w/ some adjustment, which fixes current timeout concern > >>> and also allows limited ATS support in a light way: > >>> > >>> 1) reduce spin timeout to 1ms, which can be boot-time changed > >>> up to 10ms. > > > > Out of curiosity, is there a reason to limit the timeout to 10ms? > > > > I'm generally a believer that we should do something sensible by > > default, but that an admin -- particularly someone who is going to be > > messing around with this sort of setting -- should be allowed to "shoot > > themselves in the foot" if they want to. > > > > Suppose that there's some particularly grotty piece of hardware that > > really does require a 30ms, or 100ms timeout to work effectively? If we > > have a hard limit of 10ms, there's nothing the person can do other than > > re-compile Xen. If we have no hard limit, they can simply set it to > > 100ms as a work-around until we get asynchronous flushing working. > > Andrew requested that too, and I understood that's what's planned > to be implemented. > Yes, that's the deal. :-) Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-mingo-tip-master test] 63570: regressions - FAIL
flight 63570 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/63570/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 5 kernel-build fail REGR. vs. 60684 build-amd64-pvops 5 kernel-build fail REGR. vs. 60684 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 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-amd64-xl-pvh-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-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-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 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-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a version targeted for testing: linux57ef9fc78d55d889142c74a5f1ce4136f94e081d baseline version: linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0 Last test of basis60684 2015-08-13 04:21:46 Z 84 days Failing since 60712 2015-08-15 18:33:48
[Xen-devel] [linux-3.18 test] 63543: regressions - trouble: blocked/broken/fail/pass
flight 63543 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/63543/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 3 host-install(3) broken REGR. vs. 63369 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 63369 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail like 63369 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 63369 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 63369 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 63369 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass version targeted for testing: linuxb12403044336e7d567f309eb443aa9acf76380af baseline version: linux8341455f7f2b36212f8cdded7725e93b17f5a8fc Last test of basis63369 2015-10-29 22:43:54 Z6 days Testing same since63543 2015-11-03 18:11:46 Z1 days1 attempts People who touched revisions under test: Greg Kroah-Hartman Kosuke Tatsukawa Sasha Levin 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-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-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-xsmfail test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm
Re: [Xen-devel] [PATCH v3 2/6] xen: sched: fix locking for insert_vcpu() in credit1 and RTDS
Hi Dario,
Thank you very much for the explanation! I got it. To be specific,
2015-11-04 10:52 GMT-05:00 Dario Faggioli :
> On Wed, 2015-11-04 at 10:01 -0500, Meng Xu wrote:
> > 2015-11-04 9:12 GMT-05:00 Dario Faggioli :
> > > Just FTR (and for next time :-D), is the above something that can
> > > be
> > > interpreted as a 'Reviewed-by: Meng Xu ' ? If no (e.g.,
> > > because
> > > you haven't looking thoroughly enough to feel confident to express
> > > it),
> > > then fine, I was just asking.
> > Thank you very much for explaining this for me. :-)
> >
> > I feel confident about the changes for RTDS scheduler.
> >
> Ok.
>
> > I'm not so confident about the change in the schedule.c. To be
> > specific, this patch removes insert_vcpu in schedule_cpu_switch() in
> > schedule.c;
> >
> It removes the attempt of inserting the idle vCPU in the runqueue of
> the scheduler of the target cpupool for the pCPU.
>
> More specifically, this line:
>
> SCHED_OP(new_ops, insert_vcpu, idle);
>
I neglected the parameter "idle" here. :-)
> If we look at the various ways in which insert_vcpu is implemented, we
> have:
>
> csched_vcpu_insert:
>
> if ( !__vcpu_on_runq(svc) && vcpu_runnable(vc) && !vc->is_running )
> __runq_insert(vc->processor, svc);
>
> but the pCPU being switched is free, i.e., it is not in any cpupool,
> and it is idling. So, the idle vCPU is running, and the condition above
> is false, which means __runq_insert() is not really called.
>
> csched2_vcpu_insert:
>
> if ( ! is_idle_vcpu(vc) )
> {
> ...
> }
>
> so trying to insert the idle vCPU is actually a nop.
>
> rt_vcpu_insert:
>
> if ( is_idle_vcpu(vc) )
> return;
>
>
> a nop again.
>
>
Yes. :-) After seeing this, I recalled... :-D
> My point being that this patch actually removes nothing but a bunch of
> if()-s, with no effect at all.
>
> > I'm not so sure if it is ok to insert_vcpu when a domain is moved.
>
> >
> Hopefully, I addressed your doubts.
>
Yes. It clears my doubts. :-D
> Ok, I haven't sent v4 yet, so I'll apply it there. Thanks.
>
>
Thank you very much for your explanation!
Now I'm confident about
Reviewed-by: Meng Xu
I saw the v4 patch series that comes with the Reviewed-by above. So I think
you don't need to do anything.
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 v4 07/10] xen/blkback: pseudo support for multi hardware queues/rings
On November 4, 2015 10:02:26 PM EST, Bob Liu wrote:
>
>On 11/05/2015 10:30 AM, Konrad Rzeszutek Wilk wrote:
>> On Mon, Nov 02, 2015 at 12:21:43PM +0800, Bob Liu wrote:
>>> Preparatory patch for multiple hardware queues (rings). The number
>of
>>> rings is unconditionally set to 1, larger number will be enabled in
>next
>>> patch so as to make every single patch small and readable.
>>
>> Instead of saying 'next patch' - spell out the title of the patch.
>>
>>
>>>
>>> Signed-off-by: Arianna Avanzini
>>> Signed-off-by: Bob Liu
>>> ---
>>> drivers/block/xen-blkback/common.h | 3 +-
>>> drivers/block/xen-blkback/xenbus.c | 292
>+++--
>>> 2 files changed, 185 insertions(+), 110 deletions(-)
>>>
>>> diff --git a/drivers/block/xen-blkback/common.h
>b/drivers/block/xen-blkback/common.h
>>> index f0dd69a..4de1326 100644
>>> --- a/drivers/block/xen-blkback/common.h
>>> +++ b/drivers/block/xen-blkback/common.h
>>> @@ -341,7 +341,8 @@ struct xen_blkif {
>>> struct work_struct free_work;
>>> unsigned int nr_ring_pages;
>>> /* All rings for this device */
>>> - struct xen_blkif_ring ring;
>>> + struct xen_blkif_ring *rings;
>>> + unsigned int nr_rings;
>>> };
>>>
>>> struct seg_buf {
>>> diff --git a/drivers/block/xen-blkback/xenbus.c
>b/drivers/block/xen-blkback/xenbus.c
>>> index 7bdd5fd..ac4b458 100644
>>> --- a/drivers/block/xen-blkback/xenbus.c
>>> +++ b/drivers/block/xen-blkback/xenbus.c
>>> @@ -84,11 +84,12 @@ static int blkback_name(struct xen_blkif *blkif,
>char *buf)
>>>
>>> static void xen_update_blkif_status(struct xen_blkif *blkif)
>>> {
>>> - int err;
>>> + int err, i;
>>
>> unsigned int.
>>> char name[BLKBACK_NAME_LEN];
>>> + struct xen_blkif_ring *ring;
>>>
>>> /* Not ready to connect? */
>>> - if (!blkif->ring.irq || !blkif->vbd.bdev)
>>> + if (!blkif->rings || !blkif->rings[0].irq || !blkif->vbd.bdev)
>>> return;
>>>
>>> /* Already connected? */
>>> @@ -113,19 +114,57 @@ static void xen_update_blkif_status(struct
>xen_blkif *blkif)
>>> }
>>> invalidate_inode_pages2(blkif->vbd.bdev->bd_inode->i_mapping);
>>>
>>> - blkif->ring.xenblkd = kthread_run(xen_blkif_schedule,
>&blkif->ring, "%s", name);
>>> - if (IS_ERR(blkif->ring.xenblkd)) {
>>> - err = PTR_ERR(blkif->ring.xenblkd);
>>> - blkif->ring.xenblkd = NULL;
>>> - xenbus_dev_error(blkif->be->dev, err, "start xenblkd");
>>> - return;
>>> + if (blkif->nr_rings == 1) {
>>> + blkif->rings[0].xenblkd = kthread_run(xen_blkif_schedule,
>&blkif->rings[0], "%s", name);
>>> + if (IS_ERR(blkif->rings[0].xenblkd)) {
>>> + err = PTR_ERR(blkif->rings[0].xenblkd);
>>> + blkif->rings[0].xenblkd = NULL;
>>> + xenbus_dev_error(blkif->be->dev, err, "start xenblkd");
>>> + return;
>>> + }
>>> + } else {
>>> + for (i = 0; i < blkif->nr_rings; i++) {
>>> + ring = &blkif->rings[i];
>>> + ring->xenblkd = kthread_run(xen_blkif_schedule, ring,
>>> "%s-%d",
>name, i);
>>> + if (IS_ERR(ring->xenblkd)) {
>>> + err = PTR_ERR(ring->xenblkd);
>>> + ring->xenblkd = NULL;
>>> + xenbus_dev_error(blkif->be->dev, err,
>>> + "start %s-%d xenblkd", name, i);
>>> + return;
>>> + }
>>> + }
>>
>> Please collapse this together and just have one loop.
>>
>> And just use the same name throughout ('%s-%d')
>>
>> Also this does not take care of actually freeing the allocated
>> ring->xenblkd if one of them fails to start.
>>
>> Hmm, looking at this function .. we seem to forget to change the
>> state if something fails.
>>
>> As in, connect switches the state to Connected.. And if anything
>blows
>> up after the connect() we don't switch the state. We do report an
>error
>> in the XenBus, but the state is the same.
>>
>> We should be using xenbus_dev_fatal I believe - so at least the state
>> changes to Closing (and then the frontend can switch itself to
>> Closing->Closed) - and we will call 'xen_blkif_disconnect' on Closed.
>
>>
>
>Will update..
>
>>> + }
>>> +}
>>> +
>>> +static int xen_blkif_alloc_rings(struct xen_blkif *blkif)
>>> +{
>>> + int r;
>>
>> unsigned int i;
>>
>>> +
>>> + blkif->rings = kzalloc(blkif->nr_rings * sizeof(struct
>xen_blkif_ring), GFP_KERNEL);
>>> + if (!blkif->rings)
>>> + return -ENOMEM;
>>> +
>>> + for (r = 0; r < blkif->nr_rings; r++) {
>>> + struct xen_blkif_ring *ring = &blkif->rings[r];
>>> +
>>> + spin_lock_init(&ring->blk_ring_lock);
>>> + init_waitqueue_head(&ring->wq);
>>> + INIT_LIST_HEAD(&ring->pending_free);
>>> +
>>> + spin_lock_init(&ring->pending_free_lock);
>>> + i
Re: [Xen-devel] [PATCH v1 08/11] xsplice: Implement support for applying patches
. snip..
> +void do_xsplice(void)
> +{
.. snip..
> +
> +xsplice_work.do_work = 0;
= false
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 08/11] xsplice: Implement support for applying patches
On Tue, Nov 03, 2015 at 06:16:05PM +, Ross Lagerwall wrote:
> Implement support for the apply, revert and replace actions.
>
> To perform and action on a payload, the hypercall sets up a data
> structure to schedule the work. A hook is added in all the
> return-to-guest paths to check for work to do and execute it if needed.
> In this way, patches can be applied with all CPUs idle and without
> stacks. The first CPU to do_xsplice() becomes the master and triggers a
> reschedule softirq to trigger all the other CPUs to enter do_xsplice()
> with no stack. Once all CPUs have rendezvoused, all CPUs disable IRQs
> and NMIs are ignored. The system is then quiscient and the master
> performs the action. After this, all CPUs enable IRQs and NMIs are
> re-enabled.
>
> The action to perform is one of:
> - APPLY: For each function in the module, store the first 5 bytes of the
> old function and replace it with a jump to the new function.
> - REVERT: Copy the previously stored bytes into the first 5 bytes of the
> old function.
> - REPLACE: Revert each applied module and then apply the new module.
>
> To prevent a deadlock with any other barrier in the system, the master
> will wait for up to 30ms before timing out. I've taken some
> measurements and found the patch application to take about 100 μs on a
> 72 CPU system, whether idle or fully loaded.
>
> Signed-off-by: Ross Lagerwall
> ---
> xen/arch/arm/xsplice.c | 8 ++
> xen/arch/x86/domain.c | 4 +
> xen/arch/x86/hvm/svm/svm.c | 2 +
> xen/arch/x86/hvm/vmx/vmcs.c | 2 +
> xen/arch/x86/xsplice.c | 19
> xen/common/xsplice.c| 264
> ++--
> xen/include/asm-arm/nmi.h | 13 +++
> xen/include/xen/xsplice.h | 7 +-
> 8 files changed, 306 insertions(+), 13 deletions(-)
>
> diff --git a/xen/arch/arm/xsplice.c b/xen/arch/arm/xsplice.c
> index 8d85fa9..3c34eb3 100644
> --- a/xen/arch/arm/xsplice.c
> +++ b/xen/arch/arm/xsplice.c
> @@ -3,6 +3,14 @@
> #include
> #include
>
> +void xsplice_apply_jmp(struct xsplice_patch_func *func)
> +{
> +}
> +
> +void xsplice_revert_jmp(struct xsplice_patch_func *func)
> +{
> +}
> +
> int xsplice_verify_elf(uint8_t *data, ssize_t len)
> {
> return -ENOSYS;
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index fe3be30..4420cfc 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -120,6 +121,7 @@ static void idle_loop(void)
> (*pm_idle)();
> do_tasklet();
> do_softirq();
> +do_xsplice();
> }
> }
>
> @@ -136,6 +138,7 @@ void startup_cpu_idle_loop(void)
>
> static void noreturn continue_idle_domain(struct vcpu *v)
> {
> +do_xsplice();
> reset_stack_and_jump(idle_loop);
> }
>
> @@ -143,6 +146,7 @@ static void noreturn continue_nonidle_domain(struct vcpu
> *v)
> {
> check_wakeup_from_wait();
> mark_regs_dirty(guest_cpu_user_regs());
> +do_xsplice();
> reset_stack_and_jump(ret_from_intr);
> }
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 8de41fa..65bf7e9 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1071,6 +1072,7 @@ static void noreturn svm_do_resume(struct vcpu *v)
>
> hvm_do_resume(v);
>
> +do_xsplice();
> reset_stack_and_jump(svm_asm_do_resume);
> }
>
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index 4ea1ad1..d996f47 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1685,6 +1686,7 @@ void vmx_do_resume(struct vcpu *v)
> }
>
> hvm_do_resume(v);
> +do_xsplice();
> reset_stack_and_jump(vmx_asm_do_vmentry);
> }
>
> diff --git a/xen/arch/x86/xsplice.c b/xen/arch/x86/xsplice.c
> index dbff0d5..31e4124 100644
> --- a/xen/arch/x86/xsplice.c
> +++ b/xen/arch/x86/xsplice.c
> @@ -3,6 +3,25 @@
> #include
> #include
>
> +#define PATCH_INSN_SIZE 5
> +
> +void xsplice_apply_jmp(struct xsplice_patch_func *func)
Don't we want for it to be 'int'
> +{
> +uint32_t val;
> +uint8_t *old_ptr;
> +
> +old_ptr = (uint8_t *)func->old_addr;
> +memcpy(func->undo, old_ptr, PATCH_INSN_SIZE);
And perhaps use something which can catch an exception (#GP) so that
this can error out?
> +*old_ptr++ = 0xe9; /* Relative jump */
> +val = func->new_addr - func->old_addr - PATCH_INSN_SIZE;
> +memcpy(old_ptr, &val, sizeof val);
> +}
> +
> +void xsplice_revert_jmp(struct xsplice_patch_func *func)
> +{
> +memcpy((void *)func->old_addr, func->undo, PATCH_INSN_SIZE);
> +}
> +
> int xsplice_verify_elf(uint8_t *data,
Re: [Xen-devel] [PATCH v4 07/10] xen/blkback: pseudo support for multi hardware queues/rings
On 11/05/2015 10:30 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:43PM +0800, Bob Liu wrote:
>> Preparatory patch for multiple hardware queues (rings). The number of
>> rings is unconditionally set to 1, larger number will be enabled in next
>> patch so as to make every single patch small and readable.
>
> Instead of saying 'next patch' - spell out the title of the patch.
>
>
>>
>> Signed-off-by: Arianna Avanzini
>> Signed-off-by: Bob Liu
>> ---
>> drivers/block/xen-blkback/common.h | 3 +-
>> drivers/block/xen-blkback/xenbus.c | 292
>> +++--
>> 2 files changed, 185 insertions(+), 110 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkback/common.h
>> b/drivers/block/xen-blkback/common.h
>> index f0dd69a..4de1326 100644
>> --- a/drivers/block/xen-blkback/common.h
>> +++ b/drivers/block/xen-blkback/common.h
>> @@ -341,7 +341,8 @@ struct xen_blkif {
>> struct work_struct free_work;
>> unsigned int nr_ring_pages;
>> /* All rings for this device */
>> -struct xen_blkif_ring ring;
>> +struct xen_blkif_ring *rings;
>> +unsigned int nr_rings;
>> };
>>
>> struct seg_buf {
>> diff --git a/drivers/block/xen-blkback/xenbus.c
>> b/drivers/block/xen-blkback/xenbus.c
>> index 7bdd5fd..ac4b458 100644
>> --- a/drivers/block/xen-blkback/xenbus.c
>> +++ b/drivers/block/xen-blkback/xenbus.c
>> @@ -84,11 +84,12 @@ static int blkback_name(struct xen_blkif *blkif, char
>> *buf)
>>
>> static void xen_update_blkif_status(struct xen_blkif *blkif)
>> {
>> -int err;
>> +int err, i;
>
> unsigned int.
>> char name[BLKBACK_NAME_LEN];
>> +struct xen_blkif_ring *ring;
>>
>> /* Not ready to connect? */
>> -if (!blkif->ring.irq || !blkif->vbd.bdev)
>> +if (!blkif->rings || !blkif->rings[0].irq || !blkif->vbd.bdev)
>> return;
>>
>> /* Already connected? */
>> @@ -113,19 +114,57 @@ static void xen_update_blkif_status(struct xen_blkif
>> *blkif)
>> }
>> invalidate_inode_pages2(blkif->vbd.bdev->bd_inode->i_mapping);
>>
>> -blkif->ring.xenblkd = kthread_run(xen_blkif_schedule, &blkif->ring,
>> "%s", name);
>> -if (IS_ERR(blkif->ring.xenblkd)) {
>> -err = PTR_ERR(blkif->ring.xenblkd);
>> -blkif->ring.xenblkd = NULL;
>> -xenbus_dev_error(blkif->be->dev, err, "start xenblkd");
>> -return;
>> +if (blkif->nr_rings == 1) {
>> +blkif->rings[0].xenblkd = kthread_run(xen_blkif_schedule,
>> &blkif->rings[0], "%s", name);
>> +if (IS_ERR(blkif->rings[0].xenblkd)) {
>> +err = PTR_ERR(blkif->rings[0].xenblkd);
>> +blkif->rings[0].xenblkd = NULL;
>> +xenbus_dev_error(blkif->be->dev, err, "start xenblkd");
>> +return;
>> +}
>> +} else {
>> +for (i = 0; i < blkif->nr_rings; i++) {
>> +ring = &blkif->rings[i];
>> +ring->xenblkd = kthread_run(xen_blkif_schedule, ring,
>> "%s-%d", name, i);
>> +if (IS_ERR(ring->xenblkd)) {
>> +err = PTR_ERR(ring->xenblkd);
>> +ring->xenblkd = NULL;
>> +xenbus_dev_error(blkif->be->dev, err,
>> +"start %s-%d xenblkd", name, i);
>> +return;
>> +}
>> +}
>
> Please collapse this together and just have one loop.
>
> And just use the same name throughout ('%s-%d')
>
> Also this does not take care of actually freeing the allocated
> ring->xenblkd if one of them fails to start.
>
> Hmm, looking at this function .. we seem to forget to change the
> state if something fails.
>
> As in, connect switches the state to Connected.. And if anything blows
> up after the connect() we don't switch the state. We do report an error
> in the XenBus, but the state is the same.
>
> We should be using xenbus_dev_fatal I believe - so at least the state
> changes to Closing (and then the frontend can switch itself to
> Closing->Closed) - and we will call 'xen_blkif_disconnect' on Closed.
>
Will update..
>> +}
>> +}
>> +
>> +static int xen_blkif_alloc_rings(struct xen_blkif *blkif)
>> +{
>> +int r;
>
> unsigned int i;
>
>> +
>> +blkif->rings = kzalloc(blkif->nr_rings * sizeof(struct xen_blkif_ring),
>> GFP_KERNEL);
>> +if (!blkif->rings)
>> +return -ENOMEM;
>> +
>> +for (r = 0; r < blkif->nr_rings; r++) {
>> +struct xen_blkif_ring *ring = &blkif->rings[r];
>> +
>> +spin_lock_init(&ring->blk_ring_lock);
>> +init_waitqueue_head(&ring->wq);
>> +INIT_LIST_HEAD(&ring->pending_free);
>> +
>> +spin_lock_init(&ring->pending_free_lock);
>> +init_waitqueue_head(&ring->pending_free_wq);
>> +init_waitqueue_head(&ring->shutdown_wq);
>> +
[Xen-devel] [xen-unstable test] 63540: regressions - FAIL
flight 63540 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/63540/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail REGR. vs. 63475 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail like 63475 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 63475 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 63475 Tests which did not succeed, but are not blocking: 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-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-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-xl-rtds 16 guest-start/debian.repeatfail 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 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-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-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-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 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-amd64-i386-libvirt-xsm 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 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass version targeted for testing: xen 990ea04ebedf543156dc2afa980061eb6645c390 baseline version: xen e294a0c3af9f4443dc692b180fb1771b1cb075e8 Last test of basis63475 2015-11-02 05:45:42 Z2 days Testing same since63540 2015-11-03 16:02:15 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Dario Faggioli George Dunlap Ian Campbell Jan Beulich Kun Suo 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 build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen
Re: [Xen-devel] [PATCH v4 10/10] xen/blkback: make pool of persistent grants and free pages per-queue
On 11/05/2015 10:43 AM, Konrad Rzeszutek Wilk wrote: > On Mon, Nov 02, 2015 at 12:21:46PM +0800, Bob Liu wrote: >> Make pool of persistent grants and free pages per-queue/ring instead of >> per-device to get better scalability. > > How much better scalability do we get? > Which already showed in [00/10], I paste them here: domU(orig) 4 queues8 queues16 queues iops:690k 1024k(+30%) 800k750k After patch 9 and 10: domU(orig) 4 queues8 queues16 queues iops:690k 1600k(+100%) 1450k1320k Chart: https://www.dropbox.com/s/agrcy2pbzbsvmwv/iops.png?dl=0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 10/10] xen/blkback: make pool of persistent grants and free pages per-queue
On Mon, Nov 02, 2015 at 12:21:46PM +0800, Bob Liu wrote:
> Make pool of persistent grants and free pages per-queue/ring instead of
> per-device to get better scalability.
How much better scalability do we get?
.. snip ..
>
>
> /*
> - * pers_gnts_lock must be used around all the persistent grant helpers
> - * because blkback may use multi-thread/queue for each backend.
> + * We don't need locking around the persistent grant helpers
> + * because blkback uses a single-thread for each backed, so we
s/backed/backend/
> + * can be sure that this functions will never be called recursively.
> + *
> + * The only exception to that is put_persistent_grant, that can be called
> + * from interrupt context (by xen_blkbk_unmap), so we have to use atomic
> + * bit operations to modify the flags of a persistent grant and to count
> + * the number of used grants.
> */
..snip..
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -282,6 +282,22 @@ struct xen_blkif_ring {
> spinlock_t pending_free_lock;
> wait_queue_head_t pending_free_wq;
>
> + /* buffer of free pages to map grant refs */
Full stop.
> + spinlock_t free_pages_lock;
> + int free_pages_num;
> + struct list_headfree_pages;
> +
> + /* tree to store persistent grants */
Full stop.
> + spinlock_t pers_gnts_lock;
> + struct rb_root persistent_gnts;
> + unsigned intpersistent_gnt_c;
> + atomic_tpersistent_gnt_in_use;
> + unsigned long next_lru;
> +
> + /* used by the kworker that offload work from the persistent purge */
Full stop.
> + struct list_headpersistent_purge_list;
> + struct work_struct persistent_purge_work;
> +
> /* statistics */
> unsigned long st_print;
> unsigned long long st_rd_req;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 09/10] xen/blkfront: make persistent grants per-queue
On Mon, Nov 02, 2015 at 12:21:45PM +0800, Bob Liu wrote:
> Make persistent grants per-queue/ring instead of per-device, so that we can
> drop the 'dev_lock' and get better scalability.
And what is the performance value for this? How much better
scalability do you get with this?
.. snip..
> @@ -1010,6 +1002,23 @@ static void blkif_free_ring(struct blkfront_ring_info
> *rinfo)
> }
> }
>
> + /* Remove all persistent grants */
Missing full stop.
> + if (!list_empty(&rinfo->grants)) {
> + list_for_each_entry_safe(persistent_gnt, n,
> + &rinfo->grants, node) {
> + list_del(&persistent_gnt->node);
> + if (persistent_gnt->gref != GRANT_INVALID_REF) {
> + gnttab_end_foreign_access(persistent_gnt->gref,
> + 0, 0UL);
> + rinfo->persistent_gnts_c--;
> + }
> + if (info->feature_persistent)
> + __free_page(pfn_to_page(persistent_gnt->pfn));
> + kfree(persistent_gnt);
> + }
> + }
> + BUG_ON(rinfo->persistent_gnts_c != 0);
> +
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 08/10] xen/blkback: get the number of hardware queues/rings from blkfront
On Mon, Nov 02, 2015 at 12:21:44PM +0800, Bob Liu wrote:
> Backend advertises "multi-queue-max-queues" to front, then get the negotiated
s/then/so/
> number from "multi-queue-num-queues" wrote by blkfront.
s/wrote/written/
>
> Signed-off-by: Bob Liu
> ---
> drivers/block/xen-blkback/blkback.c | 11 +++
> drivers/block/xen-blkback/common.h | 1 +
> drivers/block/xen-blkback/xenbus.c | 35 +--
> 3 files changed, 41 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/xen-blkback/blkback.c
> b/drivers/block/xen-blkback/blkback.c
> index eaf7ec0..107cc4a 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -83,6 +83,11 @@ module_param_named(max_persistent_grants,
> xen_blkif_max_pgrants, int, 0644);
> MODULE_PARM_DESC(max_persistent_grants,
> "Maximum number of grants to map persistently");
>
> +unsigned int xenblk_max_queues;
Do you want a default value?
> +module_param_named(max_queues, xenblk_max_queues, uint, 0644);
> +MODULE_PARM_DESC(max_queues,
> + "Maximum number of hardware queues per virtual disk");
> +
> /*
> * Maximum order of pages to be used for the shared ring between front and
> * backend, 4KB page granularity is used.
> @@ -1478,6 +1483,12 @@ static int __init xen_blkif_init(void)
> xen_blkif_max_ring_order = XENBUS_MAX_RING_PAGE_ORDER;
> }
>
> + /* Allow as many queues as there are CPUs if user has not
> + * specified a value.
That should be part of the module_param actually.
> + */
> + if (xenblk_max_queues == 0)
> + xenblk_max_queues = num_online_cpus();
> +
> rc = xen_blkif_interface_init();
> if (rc)
> goto failed_init;
> diff --git a/drivers/block/xen-blkback/common.h
> b/drivers/block/xen-blkback/common.h
> index 4de1326..fb28b91 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -45,6 +45,7 @@
> #include
>
> extern unsigned int xen_blkif_max_ring_order;
> +extern unsigned int xenblk_max_queues;
> /*
> * This is the maximum number of segments that would be allowed in indirect
> * requests. This value will also be passed to the frontend.
> diff --git a/drivers/block/xen-blkback/xenbus.c
> b/drivers/block/xen-blkback/xenbus.c
> index ac4b458..cafbadd 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -181,12 +181,6 @@ static struct xen_blkif *xen_blkif_alloc(domid_t domid)
> INIT_LIST_HEAD(&blkif->persistent_purge_list);
> INIT_WORK(&blkif->persistent_purge_work, xen_blkbk_unmap_purged_grants);
>
> - blkif->nr_rings = 1;
> - if (xen_blkif_alloc_rings(blkif)) {
> - kmem_cache_free(xen_blkif_cachep, blkif);
> - return ERR_PTR(-ENOMEM);
> - }
> -
> return blkif;
> }
>
> @@ -606,6 +600,14 @@ static int xen_blkbk_probe(struct xenbus_device *dev,
> goto fail;
> }
>
> + /* Multi-queue: write how many queues are supported by the backend. */
> + err = xenbus_printf(XBT_NIL, dev->nodename,
> + "multi-queue-max-queues", "%u", xenblk_max_queues);
> + if (err) {
> + pr_warn("Error writing multi-queue-num-queues\n");
> + goto fail;
Why fail? If we can't - then we can't and won't advertise this support.
We should still be able to work, right?
That is how the ''max-ring-page-order' does it below.
> + }
> +
> /* setup back pointer */
> be->blkif->be = be;
>
> @@ -997,6 +999,7 @@ static int connect_ring(struct backend_info *be)
> char *xspath;
> size_t xspathsize;
> const size_t xenstore_path_ext_size = 11; /* sufficient for
> "/queue-NNN" */
> + unsigned int requested_num_queues = 0;
>
> pr_debug("%s %s\n", __func__, dev->otherend);
>
> @@ -1024,6 +1027,26 @@ static int connect_ring(struct backend_info *be)
> be->blkif->vbd.feature_gnt_persistent = pers_grants;
> be->blkif->vbd.overflow_max_grants = 0;
>
> + /*
> + * Read the number of hardware queues from frontend.
> + */
> + err = xenbus_scanf(XBT_NIL, dev->otherend, "multi-queue-num-queues",
> "%u", &requested_num_queues);
Please split this in two lines.
> + if (err < 0) {
> + requested_num_queues = 1;
> + } else {
> + if (requested_num_queues > xenblk_max_queues
> + || requested_num_queues == 0) {
> + /* buggy or malicious guest */
> + xenbus_dev_fatal(dev, err,
> + "guest requested %u queues, exceeding
> the maximum of %u.",
> + requested_num_queues,
> xenblk_max_queues);
> + return -1;
> + }
> + }
> + be->blkif->nr_rings = requested_num_queues;
> + if (xen_blkif_alloc_rings(be->blkif))
> +
Re: [Xen-devel] [PATCH v4 07/10] xen/blkback: pseudo support for multi hardware queues/rings
On Mon, Nov 02, 2015 at 12:21:43PM +0800, Bob Liu wrote:
> Preparatory patch for multiple hardware queues (rings). The number of
> rings is unconditionally set to 1, larger number will be enabled in next
> patch so as to make every single patch small and readable.
Instead of saying 'next patch' - spell out the title of the patch.
>
> Signed-off-by: Arianna Avanzini
> Signed-off-by: Bob Liu
> ---
> drivers/block/xen-blkback/common.h | 3 +-
> drivers/block/xen-blkback/xenbus.c | 292
> +++--
> 2 files changed, 185 insertions(+), 110 deletions(-)
>
> diff --git a/drivers/block/xen-blkback/common.h
> b/drivers/block/xen-blkback/common.h
> index f0dd69a..4de1326 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -341,7 +341,8 @@ struct xen_blkif {
> struct work_struct free_work;
> unsigned int nr_ring_pages;
> /* All rings for this device */
> - struct xen_blkif_ring ring;
> + struct xen_blkif_ring *rings;
> + unsigned int nr_rings;
> };
>
> struct seg_buf {
> diff --git a/drivers/block/xen-blkback/xenbus.c
> b/drivers/block/xen-blkback/xenbus.c
> index 7bdd5fd..ac4b458 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -84,11 +84,12 @@ static int blkback_name(struct xen_blkif *blkif, char
> *buf)
>
> static void xen_update_blkif_status(struct xen_blkif *blkif)
> {
> - int err;
> + int err, i;
unsigned int.
> char name[BLKBACK_NAME_LEN];
> + struct xen_blkif_ring *ring;
>
> /* Not ready to connect? */
> - if (!blkif->ring.irq || !blkif->vbd.bdev)
> + if (!blkif->rings || !blkif->rings[0].irq || !blkif->vbd.bdev)
> return;
>
> /* Already connected? */
> @@ -113,19 +114,57 @@ static void xen_update_blkif_status(struct xen_blkif
> *blkif)
> }
> invalidate_inode_pages2(blkif->vbd.bdev->bd_inode->i_mapping);
>
> - blkif->ring.xenblkd = kthread_run(xen_blkif_schedule, &blkif->ring,
> "%s", name);
> - if (IS_ERR(blkif->ring.xenblkd)) {
> - err = PTR_ERR(blkif->ring.xenblkd);
> - blkif->ring.xenblkd = NULL;
> - xenbus_dev_error(blkif->be->dev, err, "start xenblkd");
> - return;
> + if (blkif->nr_rings == 1) {
> + blkif->rings[0].xenblkd = kthread_run(xen_blkif_schedule,
> &blkif->rings[0], "%s", name);
> + if (IS_ERR(blkif->rings[0].xenblkd)) {
> + err = PTR_ERR(blkif->rings[0].xenblkd);
> + blkif->rings[0].xenblkd = NULL;
> + xenbus_dev_error(blkif->be->dev, err, "start xenblkd");
> + return;
> + }
> + } else {
> + for (i = 0; i < blkif->nr_rings; i++) {
> + ring = &blkif->rings[i];
> + ring->xenblkd = kthread_run(xen_blkif_schedule, ring,
> "%s-%d", name, i);
> + if (IS_ERR(ring->xenblkd)) {
> + err = PTR_ERR(ring->xenblkd);
> + ring->xenblkd = NULL;
> + xenbus_dev_error(blkif->be->dev, err,
> + "start %s-%d xenblkd", name, i);
> + return;
> + }
> + }
Please collapse this together and just have one loop.
And just use the same name throughout ('%s-%d')
Also this does not take care of actually freeing the allocated
ring->xenblkd if one of them fails to start.
Hmm, looking at this function .. we seem to forget to change the
state if something fails.
As in, connect switches the state to Connected.. And if anything blows
up after the connect() we don't switch the state. We do report an error
in the XenBus, but the state is the same.
We should be using xenbus_dev_fatal I believe - so at least the state
changes to Closing (and then the frontend can switch itself to
Closing->Closed) - and we will call 'xen_blkif_disconnect' on Closed.
> + }
> +}
> +
> +static int xen_blkif_alloc_rings(struct xen_blkif *blkif)
> +{
> + int r;
unsigned int i;
> +
> + blkif->rings = kzalloc(blkif->nr_rings * sizeof(struct xen_blkif_ring),
> GFP_KERNEL);
> + if (!blkif->rings)
> + return -ENOMEM;
> +
> + for (r = 0; r < blkif->nr_rings; r++) {
> + struct xen_blkif_ring *ring = &blkif->rings[r];
> +
> + spin_lock_init(&ring->blk_ring_lock);
> + init_waitqueue_head(&ring->wq);
> + INIT_LIST_HEAD(&ring->pending_free);
> +
> + spin_lock_init(&ring->pending_free_lock);
> + init_waitqueue_head(&ring->pending_free_wq);
> + init_waitqueue_head(&ring->shutdown_wq);
> + ring->blkif = blkif;
> + xen_blkif_get(blkif);
> }
> +
> + return 0;
> }
>
> static struct xen_blkif *xen_blkif_alloc(domid_t domid)
> {
>
Re: [Xen-devel] [V9 1/3] x86/xsaves: enable xsaves/xrstors/xsavec in xen
On Wed, Nov 04, 2015 at 10:04:33AM -0700, Jan Beulich wrote:
> >>> On 03.11.15 at 07:27, wrote:
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index fe3be30..108d4f8 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -883,7 +883,12 @@ int arch_set_info_guest(
> > {
> > memcpy(v->arch.fpu_ctxt, &c.nat->fpu_ctxt,
> > sizeof(c.nat->fpu_ctxt));
> > if ( v->arch.xsave_area )
> > +{
> > v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
> > + if ( cpu_has_xsaves || cpu_has_xsavec )
> > + v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
> > +
> > XSTATE_COMPACTION_ENABLED;
> > +}
>
> So here you nicely extend the existing conditional.
>
> > @@ -1568,6 +1573,8 @@ static void __context_switch(void)
> > if ( xcr0 != get_xcr0() && !set_xcr0(xcr0) )
> > BUG();
> > }
> > +if ( cpu_has_xsaves && has_hvm_container_vcpu(n) )
> > +set_msr_xss(n->arch.hvm_vcpu.msr_xss);
>
> Why not also here (the previous if() uses cpu_has_xsave, which
> you surely depend on)? Agreed the difference is minor for modern
> CPUs, but I wanted to ask anyway. I.e. an explanation will do,
> no need to re-submit just because of this.
>
Yes. It is better to put the cpu_has_xsaves into the previous if().
> > @@ -158,6 +334,20 @@ void xsave(struct vcpu *v, uint64_t mask)
> > ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] = word_size;
> > }
> > +#define XSTATE_FIXUP ".section .fixup,\"ax\" \n"\
> > + "2: mov %5,%%ecx \n"\
> > + " xor %1,%1\n"\
> > + " rep stosb\n"\
> > + " lea %2,%0\n"\
> > + " mov %3,%1\n"\
> > + " jmp 1b \n"\
> > + ".previous \n"\
> > + _ASM_EXTABLE(1b, 2b)\
> > + : "+&D" (ptr), "+&a" (lmask)\
> > + : "m" (*ptr), "g" (lmask), "d" (hmask), \
> > + "m" (xsave_cntxt_size)\
> > + : "ecx"
> > +
> > void xrstor(struct vcpu *v, uint64_t mask)
> > {
> > uint32_t hmask = mask >> 32;
> > @@ -187,39 +377,22 @@ void xrstor(struct vcpu *v, uint64_t mask)
> > switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) )
> > {
> > default:
> > -asm volatile ( "1: .byte 0x48,0x0f,0xae,0x2f\n"
> > - ".section .fixup,\"ax\" \n"
> > - "2: mov %5,%%ecx \n"
> > - " xor %1,%1\n"
> > - " rep stosb\n"
> > - " lea %2,%0\n"
> > - " mov %3,%1\n"
> > - " jmp 1b \n"
> > - ".previous \n"
> > - _ASM_EXTABLE(1b, 2b)
> > - : "+&D" (ptr), "+&a" (lmask)
> > - : "m" (*ptr), "g" (lmask), "d" (hmask),
> > - "m" (xsave_cntxt_size)
> > - : "ecx" );
> > +alternative_input("1: "".byte 0x48,0x0f,0xae,0x2f",
> > + ".byte 0x48,0x0f,0xc7,0x1f",
> > + X86_FEATURE_XSAVES,
> > + "D" (ptr), "m" (*ptr), "a" (lmask), "d" (hmask));
> > +asm volatile (XSTATE_FIXUP);
> > break;
> > case 4: case 2:
> > -asm volatile ( "1: .byte 0x0f,0xae,0x2f\n"
> > - ".section .fixup,\"ax\" \n"
> > - "2: mov %5,%%ecx\n"
> > - " xor %1,%1 \n"
> > - " rep stosb \n"
> > - " lea %2,%0 \n"
> > - " mov %3,%1 \n"
> > - " jmp 1b \n"
> > - ".previous \n"
> > - _ASM_EXTABLE(1b, 2b)
> > - : "+&D" (ptr), "+&a" (lmask)
> > - : "m" (*ptr), "g" (lmask), "d" (hmask),
> > - "m" (xsave_cntxt_size)
> > - : "ecx" );
> > +alternative_input("1: "".byte 0x0f,0xae,0x2f",
> > + ".byte 0x0f,0xc7,0x1f",
> > + X86_FEATURE_XSAVES,
> > + "D" (ptr), "m" (*ptr), "a" (lmask), "d" (hmask));
> > +asm volatile (XSTATE_FIXUP);
> > break;
> > }
> > }
> > +#undef XSTATE_FIXUP
>
> Repea
[Xen-devel] [xen-4.5-testing baseline-only test] 38248: tolerable FAIL
This run is configured for baseline tests only. flight 38248 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38248/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 6 xen-boot fail like 38241 test-amd64-amd64-xl-credit2 21 guest-start/debian.repeatfail like 38241 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-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-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 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-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass version targeted for testing: xen e0a36c028bd6d9f50982bc2eaacadc0036267e27 baseline version: xen 423d2cd814e8460d5ea8bd191a770f3c48b3947c Last test of basis38241 2015-11-02 18:21:19 Z2 days Testing same since38248 2015-11-04 16:49:53 Z0 days1 attempts People who touched revisions under test: Jan Beulich jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass 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 test-amd64-amd64-rumpuserxen-amd64 fail test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qem
[Xen-devel] [linux-linus test] 63536: regressions - FAIL
flight 63536 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/63536/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start.2 fail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail 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-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 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 test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 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-amd64-amd64-libvirt-vhd 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 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-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-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-raw 9 debian-di-installfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass version targeted for testing: linux5062ecdb662bf3aed6dc975019c53ffcd3b01d1c baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 118 days Failing since 59348 2015-07-10 04:24:05 Z 117 days 74 attempts Testing same since63536 2015-11-03 13:50:59 Z1 days1 attempts 2531 people touched revisions under test, not listing them all 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 build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass tes
Re: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
On 11/04/2015 03:02 PM, Sander Eikelenboom wrote:
On 2015-11-04 19:47, Stephen Smalley wrote:
On 11/04/2015 01:28 PM, Sander Eikelenboom wrote:
On 2015-11-04 16:52, Stephen Smalley wrote:
On 11/04/2015 06:55 AM, Sander Eikelenboom wrote:
Hi All,
I just tried to boot with the current linus mergewindow tree under
Xen.
It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX"
option enabled.
Disabling it makes the kernel boot fine.
The splat:
[ 18.424241] Freeing unused kernel memory: 1104K
(822fc000 -
8241)
[ 18.430314] Write protecting the kernel read-only data: 18432k
[ 18.441054] Freeing unused kernel memory: 1144K
(880001ae2000 -
880001c0)
[ 18.447966] Freeing unused kernel memory: 1560K
(88000207a000 -
88000220)
[ 18.453947] BUG: unable to handle kernel paging request at
88055c883000
[ 18.459943] IP: []
ptdump_walk_pgd_level_core+0x20e/0x440
[ 18.465847] PGD 2212067 PUD 0
[ 18.471564] Oops: [#1] SMP
[ 18.477248] Modules linked in:
[ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
4.3.0-mw-20151104-linus-doflr+ #1
[ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) ,
BIOS
V1.8B1 09/13/2010
[ 18.494778] task: 880059b9 ti: 880059b98000 task.ti:
880059b98000
[ 18.500852] RIP: e030:[] []
ptdump_walk_pgd_level_core+0x20e/0x440
[ 18.507102] RSP: e02b:880059b9be48 EFLAGS: 00010296
[ 18.513351] RAX: 88055c883000 RBX: 81ae2000 RCX:
8800
[ 18.519733] RDX: 0067 RSI: 880059b9be98 RDI:
88001000
[ 18.526129] RBP: 880059b9bf00 R08: R09:
[ 18.532522] R10: 88005fd0e790 R11: 0001 R12:
88008000
[ 18.538891] R13: cfff R14: 880059b9be98 R15:
[ 18.545247] FS: () GS:88005f68()
knlGS:
[ 18.551708] CS: e033 DS: ES: CR0: 8005003b
[ 18.558153] CR2: 88055c883000 CR3: 02211000 CR4:
0660
[ 18.564686] Stack:
[ 18.571106] 000159b9be50 82211000 88055c884000
0800
[ 18.577704] 8000 88055c883000 0007
88005fd0e790
[ 18.584291] 880059b9bed8 81156ace 0001
[ 18.590916] Call Trace:
[ 18.597458] [] ? free_reserved_area+0x11e/0x120
[ 18.604180] []
ptdump_walk_pgd_level_checkwx+0x12/0x20
[ 18.611014] [] mark_rodata_ro+0xe9/0xf0
[ 18.617819] [] ? rest_init+0x80/0x80
[ 18.624512] [] kernel_init+0x18/0xe0
[ 18.631095] [] ret_from_fork+0x3f/0x70
[ 18.637650] [] ? rest_init+0x80/0x80
[ 18.644178] Code: 70 ff ff ff 48 3b 85 58 ff ff ff 0f 84 c0 fe
ff ff
48 8b 85 68 ff ff ff 48 c1 e0 10 48 c1 f8 10 48 89 45 b0 48 8b 85
70 ff
ff ff <48> 8b 38 48 85 ff 0f 85 4e ff ff ff b9 02 00 00 00 31 d2
4c 89
[ 18.658246] RIP []
ptdump_walk_pgd_level_core+0x20e/0x440
[ 18.665211] RSP
[ 18.672073] CR2: 88055c883000
[ 18.678852] ---[ end trace d84e34461c40637a ]---
[ 18.685641] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0009
[ 18.685641]
[ 18.699520] Kernel Offset: disable
What's your .config? Does cat /sys/kernel/debug/kernel_page_tables
produce a similar fault even with CONFIG_DEBUG_WX=n?
.config is attached
Hmm that sysfs file doesn't seem to exist then:
# cat /sys/kernel/debug/kernel_page_tables
cat: /sys/kernel/debug/kernel_page_tables: No such file or directory
Needs CONFIG_X86_PTDUMP=y.
Also assumes you have debugfs mounted there.
Recompiled, and the result is that it also blows up:
Can you try this:
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 1bf417e..b534216 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -362,8 +362,13 @@ static void ptdump_walk_pgd_level_core(struct
seq_file *m, pgd_t *pgd,
bool checkwx)
{
#ifdef CONFIG_X86_64
+/* 8000 - 87ff is reserved for hypervisor */
+#define is_hypervisor_range(idx) (paravirt_enabled() && \
+ ((idx >= pgd_index(__PAGE_OFFSET) - 16) && \
+ (idx < pgd_index(__PAGE_OFFSET
pgd_t *start = (pgd_t *) &init_level4_pgt;
#else
+#define is_hypervisor_range(idx) 0
pgd_t *start = swapper_pg_dir;
#endif
pgprotval_t prot;
@@ -381,7 +386,7 @@ static void ptdump_walk_pgd_level_core(struct
seq_file *m, pgd_t *pgd,
for (i = 0; i < PTRS_PER_PGD; i++) {
st.current_address = normalize_addr(i * PGD_LEVEL_MULT);
-if (!pgd_none(*start)) {
+if (!pgd_none(*start) && !is_hypervisor_range(i)) {
if (pgd_large(*start) || !pgd_present(*start)) {
prot = pgd_flags(*start);
note_page(m, &st, __pgprot(prot), 1);
___
Re: [Xen-devel] About Xen bridged pci devices and suspend/resume for the X10SAE motherboard (SuperMicro)
On Wed, 2015-11-04 at 16:06 -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Nov 04, 2015 at 02:49:11AM +0200, M. Ivanov wrote: > > Hello, > > > > I've experimented with my X10SAE and I think the problem with being > > unable to resume after suspending to RAM has something to do with the > > PCI Bridge violating the spec by trying to DMA from another address, > > since I got a DMAR error about DMA access on address 05:00.0(but in the > > bios event log it says Bus06), also the Tundra PCI Bridge is on address > > 04:00.0. (so like your case with address 7 and 8, but mine's 4 and 5), > > btw adding a PCI-E vga seems to change the addresses. > > > > > > When I disable IOMMU+Xen it works fine, so I mostly sure it's that. > > Though I've tried running just Linux with the iommu param on and I > > didn't get an error when sleeping/resuming. But I haven't tried doing a > > pass-through with it > > > > > > I've read in a previous thread about a patch of yours for the X10SAE > > problem. Which version of Xen can I use it on?(I am currently tinkering > > with 4.4.3-RELEASE). > > Oh my I can't remember. http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg02037.html I've succeeded in compiling Xen 4.4.3-RELEASE with that patch and i've also loaded the kernel module you've provided(hack.c) but I've tried changing the address to 5 instead of 7, since my Tundra is on 4. But maybe I made some mistake since it didn't make a difference, still couldn't resume from sleep. > > > > Also I take it - I need to use hack.c to tell xen to create the fake > > device,(in my case 05:00.0) and to link it with 04:00.0? But how do I > > get that file to compile? Since I don't have a makefile/etc. for it. > > So.. that motherboard is a pain to work with. I found after numerous > emails to their technical support that the PCI chipset is not capable > of dealing with VT-d. That is PCI passhtrough of any PCI devices - nada. Well, as of my new bios 3.0 I haven't tried passing through devices. But it probably works, since I could do so in 2.0a(ethernet controllers and usb controller). The only problem I've experienced is not being able to resume after suspend. > > > > Also, can't I just disable the PCI Tundra bridge somehow? And what about > > phantom pci and the pciback-hide? Can they help? > > That would be nice. If all else fails, maybe I will try modifying the BIOS with a hex editor. > > > > I've read about problems regarding the Asmedia controller, so I've > > disabled it from the bios, but that didn't help at all. > > Lets take one problem at a time. The current issue you are seeing > is suspend/resume right? That is you just booted Xen + Linux > and ran 'pm-suspend'. And the motherboard did not resume from there? > > But it works OK with Linux? > > Is AMT enabled on your setup? Hm, I will try disabling it now(since it says Enabled in the bios), but AMT doesn't work anyway since I've updated my BIOS to 3.0 and it says in the Supermicro support docs that 3.0 doesn't support AMT even though the option is in the BIOS. Will buy a Supermicro serial cable these days. Annoying that I can't use a regular one. In the meantime, I don't get it why the Xen log isn't working. I'm using the log_lvl=all and guest_loglvl=all, yet I ain't getting anything in /var/log/xen. It did work once on Fedora 22 + Xen 4.5, atm on Fedora 23 + Xen 4.5 - doesn't work, nor on Fedora 21 + Xen 4.4. > > > > > > As for my Xen crash log > > > > DMAR:[DMA Write] Request device [05:00.0] fault addr Can't remember it > > DMAR:[fault reason 02] Present bit in context entry is clear > > > > Here is my tree: > > > > 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3 Processor DRAM > > Controller (rev 06) > > 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core > > Processor PCI Express x16 Controller (rev 06) > > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 > > Processor Integrated Graphics Controller (rev 06) > > 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core > > Processor HD Audio Controller (rev 06) > > 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset > > Family USB xHCI (rev 05) > > 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series > > Chipset Family MEI Controller #1 (rev 04) > > 00:16.3 Serial controller: Intel Corporation 8 Series/C220 Series > > Chipset Family KT Controller (rev 04) > > 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection > > I217-LM (rev 05) > > 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset > > Family USB EHCI #2 (rev 05) > > 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset > > High Definition Audio Controller (rev 05) > > 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset > > Family PCI Express Root Port #1 (rev d5) > > 00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset > > Family PCI Express Root Port #4 (rev d5) > > 00:1c.5 PCI
Re: [Xen-devel] [PATCH v1 07/11] xsplice: Implement payload loading
On Tue, Nov 03, 2015 at 06:16:04PM +, Ross Lagerwall wrote:
> Add support for loading xsplice payloads. This is somewhat similar to
> the Linux kernel module loader, implementing the following steps:
> - Verify the elf file.
> - Parse the elf file.
> - Allocate a region of memory mapped within a free area of
> [xen_virt_end, XEN_VIRT_END].
> - Copy allocated sections into the new region.
> - Resolve section symbols. All other symbols must be absolute addresses.
> - Perform relocations.
> - Process xsplice specific sections.
>
> Signed-off-by: Ross Lagerwall
> ---
> xen/arch/arm/Makefile | 1 +
> xen/arch/arm/xsplice.c| 23
> xen/arch/x86/Makefile | 1 +
> xen/arch/x86/setup.c | 7 +
> xen/arch/x86/xsplice.c| 90
> xen/common/xsplice.c | 282
> ++
> xen/include/asm-x86/x86_64/page.h | 2 +
> xen/include/xen/xsplice.h | 22 +++
> 8 files changed, 428 insertions(+)
> create mode 100644 xen/arch/arm/xsplice.c
> create mode 100644 xen/arch/x86/xsplice.c
>
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 1ef39f7..f785c07 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -39,6 +39,7 @@ obj-y += device.o
> obj-y += decode.o
> obj-y += processor.o
> obj-y += smc.o
> +obj-y += xsplice.o
>
> #obj-bin-y += o
>
> diff --git a/xen/arch/arm/xsplice.c b/xen/arch/arm/xsplice.c
> new file mode 100644
> index 000..8d85fa9
> --- /dev/null
> +++ b/xen/arch/arm/xsplice.c
> @@ -0,0 +1,23 @@
> +#include
> +#include
> +#include
> +#include
> +
> +int xsplice_verify_elf(uint8_t *data, ssize_t len)
> +{
> +return -ENOSYS;
> +}
> +
> +int xsplice_perform_rel(struct xsplice_elf *elf,
> +struct xsplice_elf_sec *base,
> +struct xsplice_elf_sec *rela)
> +{
> +return -ENOSYS;
> +}
> +
> +int xsplice_perform_rela(struct xsplice_elf *elf,
> + struct xsplice_elf_sec *base,
> + struct xsplice_elf_sec *rela)
> +{
> +return -ENOSYS;
> +}
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index 39a8059..6e05532 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -61,6 +61,7 @@ obj-y += x86_emulate.o
> obj-y += tboot.o
> obj-y += hpet.o
> obj-y += vm_event.o
> +obj-y += xsplice.o
> obj-y += xstate.o
>
> obj-$(crash_debug) += gdbstub.o
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 4ed0110..a79c5e3 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -99,6 +99,9 @@ unsigned long __read_mostly xen_phys_start;
>
> unsigned long __read_mostly xen_virt_end;
>
> +unsigned long __read_mostly module_virt_start;
> +unsigned long __read_mostly module_virt_end;
> +
> DEFINE_PER_CPU(struct tss_struct, init_tss);
>
> char __section(".bss.stack_aligned") cpu0_stack[STACK_SIZE];
> @@ -1145,6 +1148,10 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> ~((1UL << L2_PAGETABLE_SHIFT) - 1);
> destroy_xen_mappings(xen_virt_end, XEN_VIRT_START + BOOTSTRAP_MAP_BASE);
>
> +module_virt_start = xen_virt_end;
> +module_virt_end = XEN_VIRT_END - NR_CPUS * PAGE_SIZE;
> +BUG_ON(module_virt_end <= module_virt_start);
> +
> memguard_init();
>
> nr_pages = 0;
> diff --git a/xen/arch/x86/xsplice.c b/xen/arch/x86/xsplice.c
> new file mode 100644
> index 000..dbff0d5
> --- /dev/null
> +++ b/xen/arch/x86/xsplice.c
> @@ -0,0 +1,90 @@
You would want to put Citrix regular Copyright header here.
> +#include
> +#include
> +#include
> +#include
> +
> +int xsplice_verify_elf(uint8_t *data, ssize_t len)
> +{
> +
> +Elf64_Ehdr *hdr = (Elf64_Ehdr *)data;
> +
> +if ( len < (sizeof *hdr) ||
> + !IS_ELF(*hdr) ||
> + hdr->e_ident[EI_CLASS] != ELFCLASS64 ||
> + hdr->e_ident[EI_DATA] != ELFDATA2LSB ||
> + hdr->e_machine != EM_X86_64 )
> +{
> +printk(XENLOG_ERR "Invalid ELF file\n");
For audit reasons I think we should have at least the name (id) that
the payload was. Could we include that as argument and
print it here?
> +return -EINVAL;
> +}
> +
> +return 0;
> +}
> +
> +int xsplice_perform_rel(struct xsplice_elf *elf,
> +struct xsplice_elf_sec *base,
> +struct xsplice_elf_sec *rela)
> +{
> +printk(XENLOG_ERR "SHT_REL relocation unsupported\n");
%s: SHR_REL relocation ..\n", elf->name);
> +return -ENOSYS;
> +}
> +
> +int xsplice_perform_rela(struct xsplice_elf *elf,
> + struct xsplice_elf_sec *base,
> + struct xsplice_elf_sec *rela)
> +{
> +Elf64_Rela *r;
> +int symndx, i;
unsigned int
> +uint64_t val;
> +uint8_t *dest;
> +
Can you double check that rela->sec-sh_entsize is not zero first?
> +for ( i = 0; i < (rela->sec->sh_size
Re: [Xen-devel] [PATCH v1 06/11] xsplice: Add helper elf routines
On Tue, Nov 03, 2015 at 06:16:03PM +, Ross Lagerwall wrote:
> Add some elf routines and data structures in preparation for loading an
> xsplice payload.
>
> Signed-off-by: Ross Lagerwall
> ---
> xen/common/Makefile | 1 +
> xen/common/xsplice_elf.c | 122
> ++
> xen/include/xen/xsplice_elf.h | 44 +++
> 3 files changed, 167 insertions(+)
> create mode 100644 xen/common/xsplice_elf.c
> create mode 100644 xen/include/xen/xsplice_elf.h
>
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 1b17c9d..de7c08a 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -57,6 +57,7 @@ obj-y += vsprintf.o
> obj-y += wait.o
> obj-y += xmalloc_tlsf.o
> obj-y += xsplice.o
> +obj-y += xsplice_elf.o
>
> obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo
> unlz4 earlycpio,$(n).init.o)
>
> diff --git a/xen/common/xsplice_elf.c b/xen/common/xsplice_elf.c
> new file mode 100644
> index 000..13a9229
> --- /dev/null
> +++ b/xen/common/xsplice_elf.c
> @@ -0,0 +1,122 @@
Do you want to add your company copyright header here?
> +#include
> +#include
> +#include
> +
> +struct xsplice_elf_sec *xsplice_elf_sec_by_name(const struct xsplice_elf
> *elf,
> +const char *name)
> +{
> +int i;
unsigned int ?
> +
> +for ( i = 0; i < elf->hdr->e_shnum; i++ )
> +{
> +if ( !strcmp(name, elf->sec[i].name) )
> +return &elf->sec[i];
> +}
> +
> +return NULL;
> +}
> +
> +static int elf_get_sections(struct xsplice_elf *elf, uint8_t *data)
> +{
> +struct xsplice_elf_sec *sec;
> +int i;
unsigned int;
Should we check the e_shnum for out of bound values? Hmm,
uint16t so not that bad..
> +
> +sec = xmalloc_array(struct xsplice_elf_sec, elf->hdr->e_shnum);
> +if ( !sec )
> +{
> +printk(XENLOG_ERR "Could not find section table\n");
Well that is not exactly right. It couldnt' allocate the memory.
Perhaps we should say:
"Could not allocate memory for %s which has %u sections!\n", elf->name,
elf->hdr->e_shnum);
> +return -ENOMEM;
> +}
> +
> +for ( i = 0; i < elf->hdr->e_shnum; i++ )
> +{
> +#ifdef CONFIG_ARM_32
> +sec[i].sec = (Elf32_Shdr *)(data + elf->hdr->e_shoff +
> +i * elf->hdr->e_shentsize);
> +#else
> +sec[i].sec = (Elf64_Shdr *)(data + elf->hdr->e_shoff +
> +i * elf->hdr->e_shentsize);
> +#endif
> +sec[i].data = data + sec[i].sec->sh_offset;
We should validate that the 'sec[i].data' pointers are not outside
the memory allocated for 'data'.
> +}
> +elf->sec = sec;
> +
> +return 0;
> +}
> +
> +static int elf_get_sym(struct xsplice_elf *elf, uint8_t *data)
> +{
> +struct xsplice_elf_sec *symtab, *strtab_sec;
> +struct xsplice_elf_sym *sym;
> +const char *strtab;
> +int i;
> +
> +symtab = xsplice_elf_sec_by_name(elf, ".symtab");
> +if ( !symtab )
> +{
> +printk(XENLOG_ERR "Could not find symbol table\n");
> +return -EINVAL;
> +}
> +
> +strtab_sec = xsplice_elf_sec_by_name(elf, ".strtab");
> +if ( !strtab_sec )
> +{
> +printk(XENLOG_ERR "Could not find string table\n");
> +return -EINVAL;
> +}
> +strtab = (const char *)(data + strtab_sec->sec->sh_offset);
Should we do a check to make sure that 'strtab' is not bigger
than the amount of memory allocated for 'data'?
> +
> +elf->nsym = symtab->sec->sh_size / symtab->sec->sh_entsize;
> +
> +sym = xmalloc_array(struct xsplice_elf_sym, elf->nsym);
Perhaps also a validity check on the elf->nsym?..
> +if ( !sym )
> +{
> +printk(XENLOG_ERR "Could not allocate memory for symbols\n");
> +return -ENOMEM;
> +}
> +
> +for ( i = 0; i < elf->nsym; i++ )
> +{
> +#ifdef CONFIG_ARM_32
> +sym[i].sym = (Elf32_Sym *)(symtab->data + i *
> symtab->sec->sh_entsize);
> +#else
> +sym[i].sym = (Elf64_Sym *)(symtab->data + i *
> symtab->sec->sh_entsize);
> +#endif
> +sym[i].name = strtab + sym[i].sym->st_name;
Could we check that the 'sym[i].name is not outside the memory allocated
for data' ?
> +}
> +elf->sym = sym;
> +
> +return 0;
> +}
> +
> +int xsplice_elf_load(struct xsplice_elf *elf, uint8_t *data, ssize_t len)
> +{
> +const char *shstrtab;
> +int i, rc;
unsigned int i;
> +
> +#ifdef CONFIG_ARM_32
> +elf->hdr = (Elf32_Ehdr *)data;
> +#else
> +elf->hdr = (Elf64_Ehdr *)data;
> +#endif
> +
> +rc = elf_get_sections(elf, data);
> +if ( rc )
> +return rc;
> +
> +shstrtab = (const char *)(data +
> elf->sec[elf->hdr->e_shstrndx].sec->sh_offset);
if (shstrtab > data + len)
return -EINVAL;
> +for ( i = 0; i < elf->hdr->e_shnum; i++ )
> +elf->sec[i].name = shstrtab + elf->sec[i].sec->sh_name;
> +
> +rc = elf_g
Re: [Xen-devel] [PATCH v1 04/11] xen-xsplice: Tool to manipulate xsplice payloads.
..snip..
Probably need this:
/* This value was choosen adhoc. It could be 42 too. */
> +#define MAX_LEN 11
> +static int list_func(int argc, char *argv[])
> +{
..snip..
> +
May be worth having an comment:
/* These MUST match to the 'action_options[]' array.
> +enum {
> +ACTION_APPLY = 0,
> +ACTION_REVERT = 1,
> +ACTION_UNLOAD = 2,
> +ACTION_CHECK = 3
And:
ACTION_REPLACE = 4,
> +};
> +
> +struct {
> +int allow; /* State it must be in to call function. */
> +int expected; /* The state to be in after the function. */
> +const char *name;
> +int (*function)(xc_interface *xch, char *id);
> +unsigned int executed; /* Has the function been called?. */
> +} action_options[] = {
> +{ .allow = XSPLICE_STATE_CHECKED,
> +.expected = XSPLICE_STATE_APPLIED,
> +.name = "apply",
> +.function = xc_xsplice_apply,
> +},
> +{ .allow = XSPLICE_STATE_APPLIED,
> +.expected = XSPLICE_STATE_CHECKED,
> +.name = "revert",
> +.function = xc_xsplice_revert,
> +},
> +{ .allow = XSPLICE_STATE_CHECKED | XSPLICE_STATE_LOADED,
> +.expected = -ENOENT,
> +.name = "unload",
> +.function = xc_xsplice_unload,
> +},
> +{ .allow = XSPLICE_STATE_CHECKED | XSPLICE_STATE_LOADED,
> +.expected = XSPLICE_STATE_CHECKED,
> +.name = "check",
> +.function = xc_xsplice_check
> +},
> +{ .allow = XSPLICE_STATE_CHECKED,
> +.expected = XSPLICE_STATE_APPLIED,
> +.name = "replace",
> +.function = xc_xsplice_replace,
> +},
> +};
> +
May want to have a comment saying what the delay is in human
values. Minutes? Seconds? Days?
> +#define RETRIES 300
> +#define DELAY 10
> +
We may want to add a comment:
/* There are functions in action_options that are called in case
* none of these match. */
> +struct {
> +const char *name;
> +int (*function)(int argc, char *argv[]);
> +} main_options[] = {
> +{ "help", help_func },
> +{ "list", list_func },
> +{ "upload", upload_func },
> +{ "all", all_func },
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 02/11] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op
On Tue, Nov 03, 2015 at 06:15:59PM +, Ross Lagerwall wrote:
> From: Konrad Rzeszutek Wilk
It is very hard for me to review my own code, but mostly
what I see are some quite simple things (really really simple)
> diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> new file mode 100644
> index 000..d984c8a
> --- /dev/null
> +++ b/xen/common/xsplice.c
> +struct payload {
> +int32_t state; /* One of XSPLICE_STATE_*. */
> +int32_t rc; /* 0 or -EXX. */
> +
> +struct list_head list; /* Linked to 'payload_list'. */
> +
> +char id[XEN_XSPLICE_NAME_SIZE + 1]; /* Name of it. */
> +};
There is some space between char and id. Actually all of these look
like they were at the same indentation but are now a bit off.
It would be nice to have them align (the comments) and the
space between 'list_head list' and 'char id' shorten.
..snip..
> +int find_payload(xen_xsplice_id_t *id, bool_t need_lock, struct payload **f)
> +{
> +struct payload *data;
> +XEN_GUEST_HANDLE_PARAM(char) str;
> +char name[XEN_XSPLICE_NAME_SIZE + 1] = { 0 }; /* 128 + 1 bytes on stack.
> Perhaps kzalloc? */
Jan was not too worried about the kzalloc so I think we can
remove the comment.
> +int rc = -EINVAL;
> +
> +rc = verify_id(id);
> +if ( rc )
> +return rc;
> +
> +str = guest_handle_cast(id->name, char);
> +if ( copy_from_guest(name, str, id->size) )
> +return -EFAULT;
> +
> +if ( need_lock )
> +spin_lock(&payload_list_lock);
> +
> +rc = -ENOENT;
> +list_for_each_entry ( data, &payload_list, list )
> +{
> +if ( !strcmp(data->id, name) )
> +{
> +*f = data;
> +rc = 0;
> +break;
> +}
> +}
> +
> +if ( need_lock )
> +spin_unlock(&payload_list_lock);
> +
> +return rc;
> +}
> +
> +
And we have an extra \n here.
.. And besides that I realized that there is some code for which
we have CONFIG_ around (lock profile, gcov, kdump?, etc). We
should probably make the xSplice code also be guarded by this
as well.
Ross, I can do these changes easily. Unless you are itching
to do it now :-)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 01/11] xsplice: Design document (v2).
On Tue, Nov 03, 2015 at 06:15:58PM +, Ross Lagerwall wrote:
> From: Konrad Rzeszutek Wilk
>
> A mechanism is required to binarily patch the running hypervisor with new
> opcodes that have come about due to primarily security updates.
>
> This document describes the design of the API that would allow us to
> upload to the hypervisor binary patches.
>
> This document has been shaped by the input from:
> Martin Pohlack
> Jan Beulich
>
> Thank you!
>
> Input-from: Martin Pohlack
> Input-from: Jan Beulich
> Signed-off-by: Konrad Rzeszutek Wilk
> Signed-off-by: Ross Lagerwall
> ---
> docs/misc/xsplice.markdown | 999
> +
:-) What a nice number!
.. sniup..
> +## Design of payload format
> +
> +The payload **MUST** contain enough data to allow us to apply the update
> +and also safely reverse it. As such we **MUST** know:
> +
> + * The locations in memory to be patched. This can be determined dynamically
> + via symbols or via virtual addresses.
> + * The new code that will be patched in.
> + * Signature to verify the payload.
Argh. We need to move the 'Signature to verify' in the 'v2' section
as I don't think we can get that done in time.
> +
> +This binary format can be constructed using an custom binary format but
> +there are severe disadvantages of it:
> +
> + * The format might need to be changed and we need an mechanism to
> accommodate
> + that.
> + * It has to be platform agnostic.
> + * Easily constructed using existing tools.
> +
> +As such having the payload in an ELF file is the sensible way. We would be
> +carrying the various sets of structures (and data) in the ELF sections under
> +different names and with definitions. The prefix for the ELF section name
> +would always be: *.xsplice* to match up to the names of the structures.
> +
> +Note that every structure has padding. This is added so that the hypervisor
> +can re-use those fields as it sees fit.
> +
> +Earlier design attempted to ineptly explain the relations of the ELF sections
> +to each other without using proper ELF mechanism (sh_info, sh_link, data
> +structures using Elf types, etc). This design will explain in detail
> +the structures and how they are used together and not dig in the ELF
> +format - except mention that the section names should match the
> +structure names.
> +
> +The xSplice payload is a relocatable ELF binary. A typical binary would have:
> +
> + * One or more .text sections
> + * Zero or more read-only data sections
> + * Zero or more data sections
> + * Relocations for each of these sections
> +
> +It may also have some architecture-specific sections. For example:
> +
> + * Alternatives instructions
> + * Bug frames
> + * Exception tables
> + * Relocations for each of these sections
> +
> +The xSplice core code loads the payload as a standard ELF binary, relocates
> it
> +and handles the architecture-specifc sections as needed. This process is much
> +like what the Linux kernel module loader does. It contains no
> xSplice-specific
> +details and thus will not be discussed further.
What is 'it'? The 'process of what module loader does'?
> +
> +Importantly, the payload also contains a section with an array of structures
> +describing the functions to be patched:
> +
> +struct xsplice_patch_func {
> +unsigned long new_addr;
> +unsigned long new_size;
> +unsigned long old_addr;
> +unsigned long old_size;
> +char *name;
> +uint8_t pad[64];
> +};
> +
Uh, so 104 bytes ? Or did you mean to s/64/24/ so the structure is nicely
padded to 64-bytes?
I think that is what you meant.
> +
> +* `old_addr` is the address of the function to be patched and is filled in at
> + compile time if the payload is statically linked and at run time if the
> + payload is dynamically linked.
> +* `new_addr` is the address of the function that is replacing the old
> + function. The address is filled in during relocation.
> +* `old_size` and `new_size` contain the sizes of the respective functions.
> +* `name` is used for looking up the old function address during dynamic
> + linking.
> +
> +The size of the `xsplice_patch_func` array is determined from the ELF section
> +size.
> +
> +During patch apply, for each `xsplice_patch_func`, the core code inserts a
> +trampoline at `old_addr` to `new_addr`. During patch revert, for each
> +`xsplice_patch_func`, the core code copies the data from the undo buffer to
> +`old_addr`.
> +
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] (XEN) APIC error on CPU0: 40(00)
On 04/11/2015 17:13, Jan Beulich wrote: On 04.11.15 at 16:15, wrote: >> Hi, >> i just build the latest 4.3.0 kernel and ran it on qubes-os with xen >> 4.4.3. I get this error just before the reboot: >> >> [(XEN) APIC error on CPU0: 40(00) > > And this appeared with the switch to kernel 4.3? No other variable > (e.g. all config options new in 4.3 turned off)? I ask because the > APIC is driven by Xen, not the kernel, and hence the kernel should > have no (direct) influence on APIC behavior. This started with 4.3.0, with 4.3.0-rc7 the system was booting properly (except for the xsave=0 workaround, without that i also get a crash dump right before the APIC error). > >> (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. >> >> I can also see some weird acpi-related messages on the log i attached, like: >> (XEN) ACPI: Invalid sleep control/status register data: 0:0x8:0x3 0:0x8:0x3 >> (XEN) ERST table was not found >> [3.608404] ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup >> failure, AE_NOT_FOUND (20150818/dswload-210) >> [3.608410] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog >> (20150818/psobject-227) >> [3.608439] ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) while >> loading table (20150818/tbxfload-193) >> [3.619914] ACPI Error: 1 table load failures, 5 successful >> (20150818/tbxfload-214) >> [3.679113] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored >> [3.688942] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep >> State [\_S1_] (20150818/hwxface-580) >> [3.688948] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep >> State [\_S2_] (20150818/hwxface-580) >> [3.756027] PM-Timer failed consistency check (0xff) - aborting. >> >> With older kernels (like 3.12 or 4.2.1) i always see those messages but >> i'm able to boot without the acpi error. > > I guess those latter messages are unrelated - not the difference > between ACPI and APIC. Also I'm unsure about you saying "boot" > here but "reboot" above? The APIC error prevents me from booting the machine, causing a forced reboot, the above messages won't. They are present even when the system starts correctly with older kernels. > >> My machine runs on skylake cpu with z170 chipset and the latest bios. >> Any ideas on how to fix this? > > Not without first figuring out what bad vector is being received > by the APIC, which likely will involved quite a bit of debugging > and code instrumentation. Do you think that this could be caused by some sort of hardware/firmware issue? Thanks, J. > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] About Xen bridged pci devices and suspend/resume for the X10SAE motherboard (SuperMicro)
On Wed, Nov 04, 2015 at 02:49:11AM +0200, M. Ivanov wrote: > Hello, > > I've experimented with my X10SAE and I think the problem with being > unable to resume after suspending to RAM has something to do with the > PCI Bridge violating the spec by trying to DMA from another address, > since I got a DMAR error about DMA access on address 05:00.0(but in the > bios event log it says Bus06), also the Tundra PCI Bridge is on address > 04:00.0. (so like your case with address 7 and 8, but mine's 4 and 5), > btw adding a PCI-E vga seems to change the addresses. > > When I disable IOMMU+Xen it works fine, so I mostly sure it's that. > Though I've tried running just Linux with the iommu param on and I > didn't get an error when sleeping/resuming. But I haven't tried doing a > pass-through with it > > I've read in a previous thread about a patch of yours for the X10SAE > problem. Which version of Xen can I use it on?(I am currently tinkering > with 4.4.3-RELEASE). Oh my I can't remember. > > Also I take it - I need to use hack.c to tell xen to create the fake > device,(in my case 05:00.0) and to link it with 04:00.0? But how do I > get that file to compile? Since I don't have a makefile/etc. for it. So.. that motherboard is a pain to work with. I found after numerous emails to their technical support that the PCI chipset is not capable of dealing with VT-d. That is PCI passhtrough of any PCI devices - nada. > > Also, can't I just disable the PCI Tundra bridge somehow? And what about > phantom pci and the pciback-hide? Can they help? That would be nice. > > I've read about problems regarding the Asmedia controller, so I've > disabled it from the bios, but that didn't help at all. Lets take one problem at a time. The current issue you are seeing is suspend/resume right? That is you just booted Xen + Linux and ran 'pm-suspend'. And the motherboard did not resume from there? But it works OK with Linux? Is AMT enabled on your setup? > > > As for my Xen crash log > > DMAR:[DMA Write] Request device [05:00.0] fault addr Can't remember it > DMAR:[fault reason 02] Present bit in context entry is clear > > Here is my tree: > > 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3 Processor DRAM > Controller (rev 06) > 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core > Processor PCI Express x16 Controller (rev 06) > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 > Processor Integrated Graphics Controller (rev 06) > 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core > Processor HD Audio Controller (rev 06) > 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset > Family USB xHCI (rev 05) > 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series > Chipset Family MEI Controller #1 (rev 04) > 00:16.3 Serial controller: Intel Corporation 8 Series/C220 Series > Chipset Family KT Controller (rev 04) > 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection > I217-LM (rev 05) > 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset > Family USB EHCI #2 (rev 05) > 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset > High Definition Audio Controller (rev 05) > 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset > Family PCI Express Root Port #1 (rev d5) > 00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset > Family PCI Express Root Port #4 (rev d5) > 00:1c.5 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset > Family PCI Express Root Port #6 (rev d5) > 00:1c.6 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset > Family PCI Express Root Port #7 (rev d5) > 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset > Family USB EHCI #1 (rev 05) > 00:1f.0 ISA bridge: Intel Corporation C226 Series Chipset Family Server > Advanced SKU LPC Controller (rev 05) > 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset > Family 6-port SATA Controller 1 [AHCI mode] (rev 05) > 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family > SMBus Controller (rev 05) > 00:1f.6 Signal processing controller: Intel Corporation 8 Series Chipset > Family Thermal Management Controller (rev 05) > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. > [AMD/ATI] Cayman PRO [Radeon HD 6950] > 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] > Cayman/Antilles HDMI Audio [Radeon HD 6900 Series] > 03:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network > Connection (rev 03) > 04:00.0 PCI bridge: Tundra Semiconductor Corp. Device 8113 (rev 01) > 05:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22A > IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx] > 06:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host > Controller (rev 02) > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
On 11/04/2015 01:47 PM, Stephen Smalley wrote: On 11/04/2015 01:28 PM, Sander Eikelenboom wrote: On 2015-11-04 16:52, Stephen Smalley wrote: On 11/04/2015 06:55 AM, Sander Eikelenboom wrote: Hi All, I just tried to boot with the current linus mergewindow tree under Xen. It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX" option enabled. Disabling it makes the kernel boot fine. The splat: [ 18.424241] Freeing unused kernel memory: 1104K (822fc000 - 8241) [ 18.430314] Write protecting the kernel read-only data: 18432k [ 18.441054] Freeing unused kernel memory: 1144K (880001ae2000 - 880001c0) [ 18.447966] Freeing unused kernel memory: 1560K (88000207a000 - 88000220) [ 18.453947] BUG: unable to handle kernel paging request at 88055c883000 [ 18.459943] IP: [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.465847] PGD 2212067 PUD 0 [ 18.471564] Oops: [#1] SMP [ 18.477248] Modules linked in: [ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.3.0-mw-20151104-linus-doflr+ #1 [ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 18.494778] task: 880059b9 ti: 880059b98000 task.ti: 880059b98000 [ 18.500852] RIP: e030:[] [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.507102] RSP: e02b:880059b9be48 EFLAGS: 00010296 [ 18.513351] RAX: 88055c883000 RBX: 81ae2000 RCX: 8800 [ 18.519733] RDX: 0067 RSI: 880059b9be98 RDI: 88001000 [ 18.526129] RBP: 880059b9bf00 R08: R09: [ 18.532522] R10: 88005fd0e790 R11: 0001 R12: 88008000 [ 18.538891] R13: cfff R14: 880059b9be98 R15: [ 18.545247] FS: () GS:88005f68() knlGS: [ 18.551708] CS: e033 DS: ES: CR0: 8005003b [ 18.558153] CR2: 88055c883000 CR3: 02211000 CR4: 0660 [ 18.564686] Stack: [ 18.571106] 000159b9be50 82211000 88055c884000 0800 [ 18.577704] 8000 88055c883000 0007 88005fd0e790 [ 18.584291] 880059b9bed8 81156ace 0001 [ 18.590916] Call Trace: [ 18.597458] [] ? free_reserved_area+0x11e/0x120 [ 18.604180] [] ptdump_walk_pgd_level_checkwx+0x12/0x20 [ 18.611014] [] mark_rodata_ro+0xe9/0xf0 [ 18.617819] [] ? rest_init+0x80/0x80 [ 18.624512] [] kernel_init+0x18/0xe0 [ 18.631095] [] ret_from_fork+0x3f/0x70 [ 18.637650] [] ? rest_init+0x80/0x80 [ 18.644178] Code: 70 ff ff ff 48 3b 85 58 ff ff ff 0f 84 c0 fe ff ff 48 8b 85 68 ff ff ff 48 c1 e0 10 48 c1 f8 10 48 89 45 b0 48 8b 85 70 ff ff ff <48> 8b 38 48 85 ff 0f 85 4e ff ff ff b9 02 00 00 00 31 d2 4c 89 [ 18.658246] RIP [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.665211] RSP [ 18.672073] CR2: 88055c883000 [ 18.678852] ---[ end trace d84e34461c40637a ]--- [ 18.685641] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [ 18.685641] [ 18.699520] Kernel Offset: disable What's your .config? Does cat /sys/kernel/debug/kernel_page_tables produce a similar fault even with CONFIG_DEBUG_WX=n? .config is attached Hmm that sysfs file doesn't seem to exist then: # cat /sys/kernel/debug/kernel_page_tables cat: /sys/kernel/debug/kernel_page_tables: No such file or directory Needs CONFIG_X86_PTDUMP=y. Also assumes you have debugfs mounted there. I don't think this code (including original page tables dump) can work on Xen PV guests: we are walking full PGD, including the hypervisor hole (entries 256-272). -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
On 2015-11-04 19:47, Stephen Smalley wrote: On 11/04/2015 01:28 PM, Sander Eikelenboom wrote: On 2015-11-04 16:52, Stephen Smalley wrote: On 11/04/2015 06:55 AM, Sander Eikelenboom wrote: Hi All, I just tried to boot with the current linus mergewindow tree under Xen. It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX" option enabled. Disabling it makes the kernel boot fine. The splat: [ 18.424241] Freeing unused kernel memory: 1104K (822fc000 - 8241) [ 18.430314] Write protecting the kernel read-only data: 18432k [ 18.441054] Freeing unused kernel memory: 1144K (880001ae2000 - 880001c0) [ 18.447966] Freeing unused kernel memory: 1560K (88000207a000 - 88000220) [ 18.453947] BUG: unable to handle kernel paging request at 88055c883000 [ 18.459943] IP: [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.465847] PGD 2212067 PUD 0 [ 18.471564] Oops: [#1] SMP [ 18.477248] Modules linked in: [ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.3.0-mw-20151104-linus-doflr+ #1 [ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 18.494778] task: 880059b9 ti: 880059b98000 task.ti: 880059b98000 [ 18.500852] RIP: e030:[] [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.507102] RSP: e02b:880059b9be48 EFLAGS: 00010296 [ 18.513351] RAX: 88055c883000 RBX: 81ae2000 RCX: 8800 [ 18.519733] RDX: 0067 RSI: 880059b9be98 RDI: 88001000 [ 18.526129] RBP: 880059b9bf00 R08: R09: [ 18.532522] R10: 88005fd0e790 R11: 0001 R12: 88008000 [ 18.538891] R13: cfff R14: 880059b9be98 R15: [ 18.545247] FS: () GS:88005f68() knlGS: [ 18.551708] CS: e033 DS: ES: CR0: 8005003b [ 18.558153] CR2: 88055c883000 CR3: 02211000 CR4: 0660 [ 18.564686] Stack: [ 18.571106] 000159b9be50 82211000 88055c884000 0800 [ 18.577704] 8000 88055c883000 0007 88005fd0e790 [ 18.584291] 880059b9bed8 81156ace 0001 [ 18.590916] Call Trace: [ 18.597458] [] ? free_reserved_area+0x11e/0x120 [ 18.604180] [] ptdump_walk_pgd_level_checkwx+0x12/0x20 [ 18.611014] [] mark_rodata_ro+0xe9/0xf0 [ 18.617819] [] ? rest_init+0x80/0x80 [ 18.624512] [] kernel_init+0x18/0xe0 [ 18.631095] [] ret_from_fork+0x3f/0x70 [ 18.637650] [] ? rest_init+0x80/0x80 [ 18.644178] Code: 70 ff ff ff 48 3b 85 58 ff ff ff 0f 84 c0 fe ff ff 48 8b 85 68 ff ff ff 48 c1 e0 10 48 c1 f8 10 48 89 45 b0 48 8b 85 70 ff ff ff <48> 8b 38 48 85 ff 0f 85 4e ff ff ff b9 02 00 00 00 31 d2 4c 89 [ 18.658246] RIP [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.665211] RSP [ 18.672073] CR2: 88055c883000 [ 18.678852] ---[ end trace d84e34461c40637a ]--- [ 18.685641] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [ 18.685641] [ 18.699520] Kernel Offset: disable What's your .config? Does cat /sys/kernel/debug/kernel_page_tables produce a similar fault even with CONFIG_DEBUG_WX=n? .config is attached Hmm that sysfs file doesn't seem to exist then: # cat /sys/kernel/debug/kernel_page_tables cat: /sys/kernel/debug/kernel_page_tables: No such file or directory Needs CONFIG_X86_PTDUMP=y. Also assumes you have debugfs mounted there. Recompiled, and the result is that it also blows up: [ 902.389247] BUG: unable to handle kernel paging request at 88055c883000 [ 902.402749] IP: [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 902.416261] PGD 2212067 PUD 0 [ 902.427768] Oops: [#1] SMP [ 902.438137] Modules linked in: [ 902.448299] CPU: 2 PID: 21951 Comm: cat Not tainted 4.3.0-mw-20151104-linus-doflr-nodebugwx-withptdump+ #1 [ 902.458581] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 902.468850] task: 88004b49e300 ti: 88005928c000 task.ti: 88005928c000 [ 902.479133] RIP: e030:[] [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 902.489536] RSP: e02b:88005928fd20 EFLAGS: 00010296 [ 902.499692] RAX: 88055c883000 RBX: RCX: 8800 [ 902.509755] RDX: 0067 RSI: 88005928fd70 RDI: 88001000 [ 902.519680] RBP: 88005928fdd8 R08: 1000 R09: [ 902.529555] R10: R11: 0246 R12: 88005928ff20 [ 902.539349] R13: cfff R14: 88005928fd70 R15: 880033c773c0 [ 902.549081] FS: 7f56b07d4700() GS:88005f68() knlGS: [ 902.558690] CS: e033 DS: ES: CR0: 8005003b [ 902.568111] CR2: 88055c883000 CR3: 4563f000 CR4: 0660 [ 902.57
[Xen-devel] [linux-3.14 test] 63533: regressions - FAIL
flight 63533 linux-3.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/63533/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 5 kernel-build fail REGR. vs. 62648 Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 62648 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62648 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail like 62648 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62648 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 62648 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 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-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 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-vhd 1 build-check(1) blocked n/a 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-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 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-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-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-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass version targeted for testing: linux07bd6f89f7ff56495c31505985af690c976374d6 baseline version: linux1230ae0e99e05ced8a945a1a2c5762ce5c6c97c9 Last test of basis62648 2015-10-03 22:43:24 Z 31 days Failing since 63225 2015-10-22 22:20:24 Z 12 days 10 attempts Testing same since63336 2015-10-27 17:53:49 Z8 days6 attempts People who touched revisions under test: "Eric W. Biederman" Aaron Conole Adam Radford Adrian Hunter Al Viro Alex Deucher Alexander Couzens Alexey Klimov Andreas Schwab Andrew Morton Andrey Vagin Andy Lutomirski Andy Shevchenko Antoine Tenart Antoine Ténart Ard Biesheuvel Arnaldo Carvalho de Melo Ben Dooks Ben Hutchings Ben Skeggs Brian Norris Charles Keepax Chris Mason Christoph Biedl Christoph Hellwig Christoph Lameter cov...@ccs.covici.com Daniel Vetter Daniel Vetter Dann Frazier Dave Airlie Dave Kleikamp David S. Miller David Vrabel David Woodhouse David Woodhouse Dirk Mueller Dirk Müller Eric Dumazet Eric W. Biederman Eryu Guan Fabiano Fidêncio Filipe Manana Frederic Weisbecker Geert Uytterhoeven Grazvydas Ignotas Greg Kroah-Hartman Guenter Roeck Guillaume Nault H. Nikolaus Schaller Herbert Xu Ian Abbott Ilya Dryomov Ingo Molnar James Bottomley James Chapman James Hogan Jan Kara Jann Horn Jarkko Nikula Jason Wang Jeff Mahoney Jenny Derzhavetz Jiri Olsa Joe Perches Joe Stringer Joe Thornber Johan Hovold John Covici John Flatness Joonsoo Kim Joonsoo Kim Julian Anastasov Kan Liang Kees Cook Konstantin Khlebnikov Krzysztof Kozlowski Kukjin Kim Linus Torvalds Liu.Zhao Mark Brown Mark Salyzyn Mathias Nyman Matt Fleming Mel Gorman Michael Ellerman Michal Hocko Michel Stam Mika Westerberg Mike Galbraith Mike Snitzer Mikulas Patocka Namhyung Kim NeilBrown Nicholas Bellinger Nicolas Pitre Oleksii Berezhniak Pablo Neira Ayuso Paolo Bonzini Paul Bolle Paul E. McKenney Paul Mackerras Paul Mackerras Pavel Roskin Peter Seiderer Peter Zijlstra (Intel) Peter Zijls
[Xen-devel] [xen-unstable-smoke test] 63624: tolerable all pass - PUSHED
flight 63624 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63624/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
version targeted for testing:
xen 6f04de658574833688c3f9eab310e7834d56a9c0
baseline version:
xen 26d4eebee81e5537dc2a04b57968ff3afe35e446
Last test of basis63615 2015-11-04 16:01:29 Z0 days
Testing same since63624 2015-11-04 18:01:19 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Bob Liu
Dario Faggioli
Harmandeep Kaur
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=6f04de658574833688c3f9eab310e7834d56a9c0
+ . ./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
6f04de658574833688c3f9eab310e7834d56a9c0
+ branch=xen-unstable-smoke
+ revision=6f04de658574833688c3f9eab310e7834d56a9c0
+ . ./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-unstable
+ '[' x6f04de658574833688c3f9eab310e7834d56a9c0 = 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
Re: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
On 11/04/2015 01:28 PM, Sander Eikelenboom wrote: On 2015-11-04 16:52, Stephen Smalley wrote: On 11/04/2015 06:55 AM, Sander Eikelenboom wrote: Hi All, I just tried to boot with the current linus mergewindow tree under Xen. It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX" option enabled. Disabling it makes the kernel boot fine. The splat: [ 18.424241] Freeing unused kernel memory: 1104K (822fc000 - 8241) [ 18.430314] Write protecting the kernel read-only data: 18432k [ 18.441054] Freeing unused kernel memory: 1144K (880001ae2000 - 880001c0) [ 18.447966] Freeing unused kernel memory: 1560K (88000207a000 - 88000220) [ 18.453947] BUG: unable to handle kernel paging request at 88055c883000 [ 18.459943] IP: [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.465847] PGD 2212067 PUD 0 [ 18.471564] Oops: [#1] SMP [ 18.477248] Modules linked in: [ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.3.0-mw-20151104-linus-doflr+ #1 [ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 18.494778] task: 880059b9 ti: 880059b98000 task.ti: 880059b98000 [ 18.500852] RIP: e030:[] [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.507102] RSP: e02b:880059b9be48 EFLAGS: 00010296 [ 18.513351] RAX: 88055c883000 RBX: 81ae2000 RCX: 8800 [ 18.519733] RDX: 0067 RSI: 880059b9be98 RDI: 88001000 [ 18.526129] RBP: 880059b9bf00 R08: R09: [ 18.532522] R10: 88005fd0e790 R11: 0001 R12: 88008000 [ 18.538891] R13: cfff R14: 880059b9be98 R15: [ 18.545247] FS: () GS:88005f68() knlGS: [ 18.551708] CS: e033 DS: ES: CR0: 8005003b [ 18.558153] CR2: 88055c883000 CR3: 02211000 CR4: 0660 [ 18.564686] Stack: [ 18.571106] 000159b9be50 82211000 88055c884000 0800 [ 18.577704] 8000 88055c883000 0007 88005fd0e790 [ 18.584291] 880059b9bed8 81156ace 0001 [ 18.590916] Call Trace: [ 18.597458] [] ? free_reserved_area+0x11e/0x120 [ 18.604180] [] ptdump_walk_pgd_level_checkwx+0x12/0x20 [ 18.611014] [] mark_rodata_ro+0xe9/0xf0 [ 18.617819] [] ? rest_init+0x80/0x80 [ 18.624512] [] kernel_init+0x18/0xe0 [ 18.631095] [] ret_from_fork+0x3f/0x70 [ 18.637650] [] ? rest_init+0x80/0x80 [ 18.644178] Code: 70 ff ff ff 48 3b 85 58 ff ff ff 0f 84 c0 fe ff ff 48 8b 85 68 ff ff ff 48 c1 e0 10 48 c1 f8 10 48 89 45 b0 48 8b 85 70 ff ff ff <48> 8b 38 48 85 ff 0f 85 4e ff ff ff b9 02 00 00 00 31 d2 4c 89 [ 18.658246] RIP [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.665211] RSP [ 18.672073] CR2: 88055c883000 [ 18.678852] ---[ end trace d84e34461c40637a ]--- [ 18.685641] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [ 18.685641] [ 18.699520] Kernel Offset: disable What's your .config? Does cat /sys/kernel/debug/kernel_page_tables produce a similar fault even with CONFIG_DEBUG_WX=n? .config is attached Hmm that sysfs file doesn't seem to exist then: # cat /sys/kernel/debug/kernel_page_tables cat: /sys/kernel/debug/kernel_page_tables: No such file or directory Needs CONFIG_X86_PTDUMP=y. Also assumes you have debugfs mounted there. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
On 2015-11-04 16:52, Stephen Smalley wrote: On 11/04/2015 06:55 AM, Sander Eikelenboom wrote: Hi All, I just tried to boot with the current linus mergewindow tree under Xen. It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX" option enabled. Disabling it makes the kernel boot fine. The splat: [ 18.424241] Freeing unused kernel memory: 1104K (822fc000 - 8241) [ 18.430314] Write protecting the kernel read-only data: 18432k [ 18.441054] Freeing unused kernel memory: 1144K (880001ae2000 - 880001c0) [ 18.447966] Freeing unused kernel memory: 1560K (88000207a000 - 88000220) [ 18.453947] BUG: unable to handle kernel paging request at 88055c883000 [ 18.459943] IP: [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.465847] PGD 2212067 PUD 0 [ 18.471564] Oops: [#1] SMP [ 18.477248] Modules linked in: [ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.3.0-mw-20151104-linus-doflr+ #1 [ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 18.494778] task: 880059b9 ti: 880059b98000 task.ti: 880059b98000 [ 18.500852] RIP: e030:[] [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.507102] RSP: e02b:880059b9be48 EFLAGS: 00010296 [ 18.513351] RAX: 88055c883000 RBX: 81ae2000 RCX: 8800 [ 18.519733] RDX: 0067 RSI: 880059b9be98 RDI: 88001000 [ 18.526129] RBP: 880059b9bf00 R08: R09: [ 18.532522] R10: 88005fd0e790 R11: 0001 R12: 88008000 [ 18.538891] R13: cfff R14: 880059b9be98 R15: [ 18.545247] FS: () GS:88005f68() knlGS: [ 18.551708] CS: e033 DS: ES: CR0: 8005003b [ 18.558153] CR2: 88055c883000 CR3: 02211000 CR4: 0660 [ 18.564686] Stack: [ 18.571106] 000159b9be50 82211000 88055c884000 0800 [ 18.577704] 8000 88055c883000 0007 88005fd0e790 [ 18.584291] 880059b9bed8 81156ace 0001 [ 18.590916] Call Trace: [ 18.597458] [] ? free_reserved_area+0x11e/0x120 [ 18.604180] [] ptdump_walk_pgd_level_checkwx+0x12/0x20 [ 18.611014] [] mark_rodata_ro+0xe9/0xf0 [ 18.617819] [] ? rest_init+0x80/0x80 [ 18.624512] [] kernel_init+0x18/0xe0 [ 18.631095] [] ret_from_fork+0x3f/0x70 [ 18.637650] [] ? rest_init+0x80/0x80 [ 18.644178] Code: 70 ff ff ff 48 3b 85 58 ff ff ff 0f 84 c0 fe ff ff 48 8b 85 68 ff ff ff 48 c1 e0 10 48 c1 f8 10 48 89 45 b0 48 8b 85 70 ff ff ff <48> 8b 38 48 85 ff 0f 85 4e ff ff ff b9 02 00 00 00 31 d2 4c 89 [ 18.658246] RIP [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.665211] RSP [ 18.672073] CR2: 88055c883000 [ 18.678852] ---[ end trace d84e34461c40637a ]--- [ 18.685641] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [ 18.685641] [ 18.699520] Kernel Offset: disable What's your .config? Does cat /sys/kernel/debug/kernel_page_tables produce a similar fault even with CONFIG_DEBUG_WX=n? .config is attached Hmm that sysfs file doesn't seem to exist then: # cat /sys/kernel/debug/kernel_page_tables cat: /sys/kernel/debug/kernel_page_tables: No such file or directory -- Sander # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 4.3.0-mw-20151104-linus-doflr Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG
Re: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
On 2015-11-04 19:06, Ingo Molnar wrote:
* Stephen Smalley wrote:
On 11/04/2015 06:55 AM, Sander Eikelenboom wrote:
>Hi All,
>
>I just tried to boot with the current linus mergewindow tree under Xen.
>It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX"
>option enabled.
>Disabling it makes the kernel boot fine.
>
>The splat:
>[ 18.424241] Freeing unused kernel memory: 1104K (822fc000 -
>8241)
>[ 18.430314] Write protecting the kernel read-only data: 18432k
>[ 18.441054] Freeing unused kernel memory: 1144K (880001ae2000 -
>880001c0)
>[ 18.447966] Freeing unused kernel memory: 1560K (88000207a000 -
>88000220)
>[ 18.453947] BUG: unable to handle kernel paging request at
>88055c883000
>[ 18.459943] IP: []
>ptdump_walk_pgd_level_core+0x20e/0x440
>[ 18.465847] PGD 2212067 PUD 0
>[ 18.471564] Oops: [#1] SMP
>[ 18.477248] Modules linked in:
>[ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
>4.3.0-mw-20151104-linus-doflr+ #1
>[ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS
>V1.8B1 09/13/2010
>[ 18.494778] task: 880059b9 ti: 880059b98000 task.ti:
>880059b98000
>[ 18.500852] RIP: e030:[] []
>ptdump_walk_pgd_level_core+0x20e/0x440
It would be nice to see which line of code this corresponds to. Doing
this:
gdb vmlinux
list *0x8105af8e
should normally do the trick.
Thanks,
Ingo
Hi Ingo,
(gdb) list *0x8105af8e
0x8105af8e is in ptdump_walk_pgd_level_core
(arch/x86/mm/dump_pagetables.c:181).
warning: Source file is more recent than executable.
176 * On 64 bits, sign-extend the 48 bit address to 64 bit
177 */
178 static unsigned long normalize_addr(unsigned long u)
179 {
180 #ifdef CONFIG_X86_64
181 return (signed long)(u << 16) >> 16;
182 #else
183 return u;
184 #endif
185 }
--
Sander
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
* Stephen Smalley wrote: > On 11/04/2015 06:55 AM, Sander Eikelenboom wrote: > >Hi All, > > > >I just tried to boot with the current linus mergewindow tree under Xen. > >It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX" > >option enabled. > >Disabling it makes the kernel boot fine. > > > >The splat: > >[ 18.424241] Freeing unused kernel memory: 1104K (822fc000 - > >8241) > >[ 18.430314] Write protecting the kernel read-only data: 18432k > >[ 18.441054] Freeing unused kernel memory: 1144K (880001ae2000 - > >880001c0) > >[ 18.447966] Freeing unused kernel memory: 1560K (88000207a000 - > >88000220) > >[ 18.453947] BUG: unable to handle kernel paging request at > >88055c883000 > >[ 18.459943] IP: [] > >ptdump_walk_pgd_level_core+0x20e/0x440 > >[ 18.465847] PGD 2212067 PUD 0 > >[ 18.471564] Oops: [#1] SMP > >[ 18.477248] Modules linked in: > >[ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted > >4.3.0-mw-20151104-linus-doflr+ #1 > >[ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS > >V1.8B1 09/13/2010 > >[ 18.494778] task: 880059b9 ti: 880059b98000 task.ti: > >880059b98000 > >[ 18.500852] RIP: e030:[] [] > >ptdump_walk_pgd_level_core+0x20e/0x440 It would be nice to see which line of code this corresponds to. Doing this: gdb vmlinux list *0x8105af8e should normally do the trick. Thanks, Ingo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 63615: tolerable all pass - PUSHED
flight 63615 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63615/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
version targeted for testing:
xen 26d4eebee81e5537dc2a04b57968ff3afe35e446
baseline version:
xen 6919a7dde48bf1a9314c328bfb93a8a2f741bb80
Last test of basis63594 2015-11-04 12:00:59 Z0 days
Testing same since63615 2015-11-04 16:01:29 Z0 days1 attempts
People who touched revisions under test:
Dario Faggioli
Ian Campbell
Ian Jackson
Ross Lagerwall
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=26d4eebee81e5537dc2a04b57968ff3afe35e446
+ . ./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
26d4eebee81e5537dc2a04b57968ff3afe35e446
+ branch=xen-unstable-smoke
+ revision=26d4eebee81e5537dc2a04b57968ff3afe35e446
+ . ./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-unstable
+ '[' x26d4eebee81e5537dc2a04b57968ff3afe35e446 = 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:
Re: [Xen-devel] [PATCH v4 1/6] xen: sched: fix locking of remove_vcpu() in credit1
On 04/11/15 17:17, Dario Faggioli wrote:
> In fact, csched_vcpu_remove() (i.e., the credit1
> implementation of remove_vcpu()) manipulates runqueues,
> so holding the runqueue lock is necessary.
>
> However, the vCPU just can't be on the runqueue, when
> the function is called. We can therefore ASSERT() that,
> and avoid doing any runqueue manipulations (rather than
> adding the runqueue locking around it).
>
> Also, while there, *_lock_irq() (for the private lock) is
> enough, there is no need to *_lock_irqsave().
>
> Signed-off-by: Dario Faggioli
Reviewed-by: George Dunlap
> ---
> Cc: George Dunlap
> Cc: Andrew Cooper
> Cc: Jan Beulich
> ---
> Changes from v3:
> * instead of adding locking, get rid of __runq_remove(),
>and add an ASSERT() about vCPU not being in runq already,
>as suggested during review.
>
> Changes from the other series:
> * split the patch (wrt the original patch, in the original
>series), and take care, in this one, only of remove_vcpu();
> * removed pointless parentheses.
> ---
> The fact that vCPU can't be in runqueue when calling remove_vcpu() is true for
> other schedulers as well. In them, though, there isn't any race condition to
> fix. Therefore, taking care of the other schedulers will happen in a followup
> series.
> ---
> xen/common/sched_credit.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index 1b30e67..6dfcff6 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -934,28 +934,25 @@ csched_vcpu_remove(const struct scheduler *ops, struct
> vcpu *vc)
> struct csched_private *prv = CSCHED_PRIV(ops);
> struct csched_vcpu * const svc = CSCHED_VCPU(vc);
> struct csched_dom * const sdom = svc->sdom;
> -unsigned long flags;
>
> SCHED_STAT_CRANK(vcpu_remove);
>
> +ASSERT(!__vcpu_on_runq(svc));
> +
> if ( test_and_clear_bit(CSCHED_FLAG_VCPU_PARKED, &svc->flags) )
> {
> SCHED_STAT_CRANK(vcpu_unpark);
> vcpu_unpause(svc->vcpu);
> }
>
> -if ( __vcpu_on_runq(svc) )
> -__runq_remove(svc);
> -
> -spin_lock_irqsave(&(prv->lock), flags);
> +spin_lock_irq(&prv->lock);
>
> if ( !list_empty(&svc->active_vcpu_elem) )
> __csched_vcpu_acct_stop_locked(prv, svc);
>
> -spin_unlock_irqrestore(&(prv->lock), flags);
> +spin_unlock_irq(&prv->lock);
>
> BUG_ON( sdom == NULL );
> -BUG_ON( !list_empty(&svc->runq_elem) );
> }
>
> static void
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/6] xen: sched: fix locking of remove_vcpu() in credit1
In fact, csched_vcpu_remove() (i.e., the credit1
implementation of remove_vcpu()) manipulates runqueues,
so holding the runqueue lock is necessary.
However, the vCPU just can't be on the runqueue, when
the function is called. We can therefore ASSERT() that,
and avoid doing any runqueue manipulations (rather than
adding the runqueue locking around it).
Also, while there, *_lock_irq() (for the private lock) is
enough, there is no need to *_lock_irqsave().
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Andrew Cooper
Cc: Jan Beulich
---
Changes from v3:
* instead of adding locking, get rid of __runq_remove(),
and add an ASSERT() about vCPU not being in runq already,
as suggested during review.
Changes from the other series:
* split the patch (wrt the original patch, in the original
series), and take care, in this one, only of remove_vcpu();
* removed pointless parentheses.
---
The fact that vCPU can't be in runqueue when calling remove_vcpu() is true for
other schedulers as well. In them, though, there isn't any race condition to
fix. Therefore, taking care of the other schedulers will happen in a followup
series.
---
xen/common/sched_credit.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 1b30e67..6dfcff6 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -934,28 +934,25 @@ csched_vcpu_remove(const struct scheduler *ops, struct
vcpu *vc)
struct csched_private *prv = CSCHED_PRIV(ops);
struct csched_vcpu * const svc = CSCHED_VCPU(vc);
struct csched_dom * const sdom = svc->sdom;
-unsigned long flags;
SCHED_STAT_CRANK(vcpu_remove);
+ASSERT(!__vcpu_on_runq(svc));
+
if ( test_and_clear_bit(CSCHED_FLAG_VCPU_PARKED, &svc->flags) )
{
SCHED_STAT_CRANK(vcpu_unpark);
vcpu_unpause(svc->vcpu);
}
-if ( __vcpu_on_runq(svc) )
-__runq_remove(svc);
-
-spin_lock_irqsave(&(prv->lock), flags);
+spin_lock_irq(&prv->lock);
if ( !list_empty(&svc->active_vcpu_elem) )
__csched_vcpu_acct_stop_locked(prv, svc);
-spin_unlock_irqrestore(&(prv->lock), flags);
+spin_unlock_irq(&prv->lock);
BUG_ON( sdom == NULL );
-BUG_ON( !list_empty(&svc->runq_elem) );
}
static void
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 4/6] xen: sched: better handle (not) inserting idle vCPUs in runqueues
Idle vCPUs are set to run immediately, as a part of their
own initialization, so we shouldn't even try to put them
in a runqueue. In fact, no scheduler does that, even when
asked to (that is rather explicit in Credit2 and RTDS, a
bit less evident in Credit1).
Let's make things look as follows:
- in generic code, explicitly avoid even trying to
insert idle vCPUs in runqueues;
- in specific schedulers' code, enforce that.
Note that, as csched_vcpu_insert() is no longer being
called, during boot (from sched_init_vcpu()) we can
safely avoid saving the flags when taking the runqueue
lock.
Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
Reviewed-by: Juergen Gross
---
Changes from v1:
* changelog: updated and made a little bit less verbose.
---
xen/common/sched_credit.c |7 ---
xen/common/sched_credit2.c | 25 ++---
xen/common/sched_rt.c |4 +---
xen/common/schedule.c | 20 +++-
4 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 0e26986..021a9dd 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -912,14 +912,15 @@ csched_vcpu_insert(const struct scheduler *ops, struct
vcpu *vc)
{
struct csched_vcpu *svc = vc->sched_priv;
spinlock_t *lock;
-unsigned long flags;
-lock = vcpu_schedule_lock_irqsave(vc, &flags);
+BUG_ON( is_idle_vcpu(vc) );
+
+lock = vcpu_schedule_lock_irq(vc);
if ( !__vcpu_on_runq(svc) && vcpu_runnable(vc) && !vc->is_running )
__runq_insert(vc->processor, svc);
-vcpu_schedule_unlock_irqrestore(lock, flags, vc);
+vcpu_schedule_unlock_irq(lock, vc);
SCHED_STAT_CRANK(vcpu_insert);
}
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index fc51a75..556ca0f 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -868,30 +868,25 @@ csched2_vcpu_insert(const struct scheduler *ops, struct
vcpu *vc)
{
struct csched2_vcpu *svc = vc->sched_priv;
struct csched2_dom * const sdom = svc->sdom;
+spinlock_t *lock;
printk("%s: Inserting %pv\n", __func__, vc);
-/* NB: On boot, idle vcpus are inserted before alloc_pdata() has
- * been called for that cpu.
- */
-if ( ! is_idle_vcpu(vc) )
-{
-spinlock_t *lock;
+BUG_ON(is_idle_vcpu(vc));
-/* FIXME: Do we need the private lock here? */
-list_add_tail(&svc->sdom_elem, &svc->sdom->vcpu);
+/* FIXME: Do we need the private lock here? */
+list_add_tail(&svc->sdom_elem, &svc->sdom->vcpu);
-/* Add vcpu to runqueue of initial processor */
-lock = vcpu_schedule_lock_irq(vc);
+/* Add vcpu to runqueue of initial processor */
+lock = vcpu_schedule_lock_irq(vc);
-runq_assign(ops, vc);
+runq_assign(ops, vc);
-vcpu_schedule_unlock_irq(lock, vc);
+vcpu_schedule_unlock_irq(lock, vc);
-sdom->nr_vcpus++;
+sdom->nr_vcpus++;
-SCHED_STAT_CRANK(vcpu_insert);
-}
+SCHED_STAT_CRANK(vcpu_insert);
CSCHED2_VCPU_CHECK(vc);
}
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 3a66c9a..cbe7b17 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -624,9 +624,7 @@ rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
s_time_t now = NOW();
spinlock_t *lock;
-/* not addlocate idle vcpu to dom vcpu list */
-if ( is_idle_vcpu(vc) )
-return;
+BUG_ON( is_idle_vcpu(vc) );
lock = vcpu_schedule_lock_irq(vc);
if ( now >= svc->cur_deadline )
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 1512d79..e3582d1 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -240,20 +240,22 @@ int sched_init_vcpu(struct vcpu *v, unsigned int
processor)
init_timer(&v->poll_timer, poll_timer_fn,
v, v->processor);
-/* Idle VCPUs are scheduled immediately. */
+v->sched_priv = SCHED_OP(DOM2OP(d), alloc_vdata, v, d->sched_priv);
+if ( v->sched_priv == NULL )
+return 1;
+
+TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, v->vcpu_id);
+
+/* Idle VCPUs are scheduled immediately, so don't put them in runqueue. */
if ( is_idle_domain(d) )
{
per_cpu(schedule_data, v->processor).curr = v;
v->is_running = 1;
}
-
-TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, v->vcpu_id);
-
-v->sched_priv = SCHED_OP(DOM2OP(d), alloc_vdata, v, d->sched_priv);
-if ( v->sched_priv == NULL )
-return 1;
-
-SCHED_OP(DOM2OP(d), insert_vcpu, v);
+else
+{
+SCHED_OP(DOM2OP(d), insert_vcpu, v);
+}
return 0;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 5/6] xen: sched: get rid of the per domain vCPU list in RTDS
As, curently, there is no reason for bothering having
it and keeping it updated.
In fact, it is only used for dumping and changing
vCPUs parameters, but that can be achieved easily with
for_each_vcpu.
While there, take care of the case when
XEN_DOMCTL_SCHEDOP_getinfo is called but no vCPUs have
been allocated yet (by returning the default scheduling
parameters).
Signed-off-by: Dario Faggioli
Reviewed-by: Meng Xu
---
Cc: George Dunlap
Cc: Andrew Cooper
---
Changes from v1:
* address the case when d->vcpu[] has not been allocated
yet, as requested during review;
* style: space before brackets of for_each_vcpu, as
requested during review;
* used 'v' instead of 'vc' for 'vcpu' (in new code).
---
xen/common/sched_rt.c | 54 -
1 file changed, 26 insertions(+), 28 deletions(-)
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index cbe7b17..3f1d047 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -160,7 +160,6 @@ struct rt_private {
*/
struct rt_vcpu {
struct list_head q_elem;/* on the runq/depletedq list */
-struct list_head sdom_elem; /* on the domain VCPU list */
/* Up-pointers */
struct rt_dom *sdom;
@@ -182,7 +181,6 @@ struct rt_vcpu {
* Domain
*/
struct rt_dom {
-struct list_head vcpu; /* link its VCPUs */
struct list_head sdom_elem; /* link list on rt_priv */
struct domain *dom; /* pointer to upper domain */
};
@@ -290,7 +288,7 @@ rt_dump_pcpu(const struct scheduler *ops, int cpu)
static void
rt_dump(const struct scheduler *ops)
{
-struct list_head *iter_sdom, *iter_svc, *runq, *depletedq, *iter;
+struct list_head *runq, *depletedq, *iter;
struct rt_private *prv = rt_priv(ops);
struct rt_vcpu *svc;
struct rt_dom *sdom;
@@ -319,14 +317,16 @@ rt_dump(const struct scheduler *ops)
}
printk("Domain info:\n");
-list_for_each( iter_sdom, &prv->sdom )
+list_for_each( iter, &prv->sdom )
{
-sdom = list_entry(iter_sdom, struct rt_dom, sdom_elem);
+struct vcpu *v;
+
+sdom = list_entry(iter, struct rt_dom, sdom_elem);
printk("\tdomain: %d\n", sdom->dom->domain_id);
-list_for_each( iter_svc, &sdom->vcpu )
+for_each_vcpu ( sdom->dom, v )
{
-svc = list_entry(iter_svc, struct rt_vcpu, sdom_elem);
+svc = rt_vcpu(v);
rt_dump_vcpu(ops, svc);
}
}
@@ -527,7 +527,6 @@ rt_alloc_domdata(const struct scheduler *ops, struct domain
*dom)
if ( sdom == NULL )
return NULL;
-INIT_LIST_HEAD(&sdom->vcpu);
INIT_LIST_HEAD(&sdom->sdom_elem);
sdom->dom = dom;
@@ -587,7 +586,6 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcpu
*vc, void *dd)
return NULL;
INIT_LIST_HEAD(&svc->q_elem);
-INIT_LIST_HEAD(&svc->sdom_elem);
svc->flags = 0U;
svc->sdom = dd;
svc->vcpu = vc;
@@ -614,8 +612,7 @@ rt_free_vdata(const struct scheduler *ops, void *priv)
* This function is called in sched_move_domain() in schedule.c
* When move a domain to a new cpupool.
* It inserts vcpus of moving domain to the scheduler's RunQ in
- * dest. cpupool; and insert rt_vcpu svc to scheduler-specific
- * vcpu list of the dom
+ * dest. cpupool.
*/
static void
rt_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
@@ -634,15 +631,11 @@ rt_vcpu_insert(const struct scheduler *ops, struct vcpu
*vc)
__runq_insert(ops, svc);
vcpu_schedule_unlock_irq(lock, vc);
-/* add rt_vcpu svc to scheduler-specific vcpu list of the dom */
-list_add_tail(&svc->sdom_elem, &svc->sdom->vcpu);
-
SCHED_STAT_CRANK(vcpu_insert);
}
/*
- * Remove rt_vcpu svc from the old scheduler in source cpupool; and
- * Remove rt_vcpu svc from scheduler-specific vcpu list of the dom
+ * Remove rt_vcpu svc from the old scheduler in source cpupool.
*/
static void
rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
@@ -659,9 +652,6 @@ rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
if ( __vcpu_on_q(svc) )
__q_remove(svc);
vcpu_schedule_unlock_irq(lock, vc);
-
-if ( !is_idle_vcpu(vc) )
-list_del_init(&svc->sdom_elem);
}
/*
@@ -1135,20 +1125,28 @@ rt_dom_cntl(
struct xen_domctl_scheduler_op *op)
{
struct rt_private *prv = rt_priv(ops);
-struct rt_dom * const sdom = rt_dom(d);
struct rt_vcpu *svc;
-struct list_head *iter;
+struct vcpu *v;
unsigned long flags;
int rc = 0;
switch ( op->cmd )
{
case XEN_DOMCTL_SCHEDOP_getinfo:
-spin_lock_irqsave(&prv->lock, flags);
-svc = list_entry(sdom->vcpu.next, struct rt_vcpu, sdom_elem);
-op->u.rtds.period = svc->period / MICROSECS(1); /* transfer to us */
-op->u.rtds.budget = svc->budget / MICROSECS(1);
-spin_unlock_irqrestore(&prv->lock, flags);
+if ( d->max_vcpus > 0 )
+{
+sp
[Xen-devel] [PATCH v4 2/6] xen: sched: fix locking for insert_vcpu() in credit1 and RTDS
The insert_vcpu() hook is handled with inconsistent locking.
In fact, schedule_cpu_switch() calls the hook with runqueue
lock held, while sched_move_domain() relies on the hook
implementations to take the lock themselves (and, since that
is not done in Credit1 and RTDS, such operation is not safe
in those cases).
This is fixed as follows:
- take the lock in the hook implementations, in specific
schedulers' code;
- avoid calling insert_vcpu(), for the idle vCPU, in
schedule_cpu_switch(). In fact, idle vCPUs are set to run
immediately, and the various schedulers won't insert them
in their runqueues anyway, even when explicitly asked to.
While there, still in schedule_cpu_switch(), locking with
_irq() is enough (there's no need to do *_irqsave()).
Signed-off-by: Dario Faggioli
Reviewed-by: Meng Xu
---
Cc: George Dunlap
Cc: Andrew Cooper
Cc: Jan Beulich
---
Cahnges from v2:
* locking in schedule_cpu_switch() is left in place (but
turned to just _irq(), instead than *_irqsave());
* call to insert_vcpu() in schedule_cpu_switch() is
removed in this patch (rather than later in the series).
Changes from v1 (of this series):
* in Credit1, the lock wants to be an _irqsave() one. If
not, the ASSERT() in _spin_lock_irq() will trigger when
the hook is called, during boot, from sched_init_vcpu();
* reprhased the changelog (to be less verbose);
* add a few words, in the changelog, about why it is safe
to get rid of the locking in schedule_cpu_switch(). Proper
commentary and ASSERT()-s about that will come in another
patch.
Changes from the other series:
* split the patch (wrt the original patch, in the original
series), and take care, in this one, only of insert_vcpu();
---
xen/common/sched_credit.c |6 ++
xen/common/sched_rt.c |3 +++
xen/common/schedule.c |6 ++
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 6dfcff6..0e26986 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -911,10 +911,16 @@ static void
csched_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
{
struct csched_vcpu *svc = vc->sched_priv;
+spinlock_t *lock;
+unsigned long flags;
+
+lock = vcpu_schedule_lock_irqsave(vc, &flags);
if ( !__vcpu_on_runq(svc) && vcpu_runnable(vc) && !vc->is_running )
__runq_insert(vc->processor, svc);
+vcpu_schedule_unlock_irqrestore(lock, flags, vc);
+
SCHED_STAT_CRANK(vcpu_insert);
}
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 822f23c..3a66c9a 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -622,16 +622,19 @@ rt_vcpu_insert(const struct scheduler *ops, struct vcpu
*vc)
{
struct rt_vcpu *svc = rt_vcpu(vc);
s_time_t now = NOW();
+spinlock_t *lock;
/* not addlocate idle vcpu to dom vcpu list */
if ( is_idle_vcpu(vc) )
return;
+lock = vcpu_schedule_lock_irq(vc);
if ( now >= svc->cur_deadline )
rt_update_deadline(now, svc);
if ( !__vcpu_on_q(svc) && vcpu_runnable(vc) && !vc->is_running )
__runq_insert(ops, svc);
+vcpu_schedule_unlock_irq(lock, vc);
/* add rt_vcpu svc to scheduler-specific vcpu list of the dom */
list_add_tail(&svc->sdom_elem, &svc->sdom->vcpu);
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 292e9a0..88e456f 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1488,7 +1488,6 @@ void __init scheduler_init(void)
int schedule_cpu_switch(unsigned int cpu, struct cpupool *c)
{
-unsigned long flags;
struct vcpu *idle;
spinlock_t *lock;
void *ppriv, *ppriv_old, *vpriv, *vpriv_old;
@@ -1509,7 +1508,7 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool
*c)
return -ENOMEM;
}
-lock = pcpu_schedule_lock_irqsave(cpu, &flags);
+lock = pcpu_schedule_lock_irq(cpu);
SCHED_OP(old_ops, tick_suspend, cpu);
vpriv_old = idle->sched_priv;
@@ -1518,9 +1517,8 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool
*c)
ppriv_old = per_cpu(schedule_data, cpu).sched_priv;
per_cpu(schedule_data, cpu).sched_priv = ppriv;
SCHED_OP(new_ops, tick_resume, cpu);
-SCHED_OP(new_ops, insert_vcpu, idle);
-pcpu_schedule_unlock_irqrestore(lock, flags, cpu);
+pcpu_schedule_unlock_irq(lock, cpu);
SCHED_OP(old_ops, free_vdata, vpriv_old);
SCHED_OP(old_ops, free_pdata, ppriv_old, cpu);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 3/6] xen: sched: clarify use cases of schedule_cpu_switch()
schedule_cpu_switch() is meant to be only used for moving
pCPUs from a cpupool to no cpupool, and from there back
to a cpupool, *not* to move them directly from one cpupool
to another.
This is something inherent to the way the function is
implemented and called, but is not that clear, just by the
look of it.
Make it more evident by:
- adding commentary and ASSERT()s;
- update the cpupool per-CPU variable (mapping pCPUs to
pools) directly in schedule_cpu_switch(), rather than
in various places in cpupool.c.
Signed-off-by: Dario Faggioli
Acked-by: Juergen Gross
Reviewed-by: George Dunlap
---
Cc: Jan Beulich
---
Changes from v2:
* updating of per_cpu(cpupool, cpu) is now done in
schedule_cpu_switch(), as suggested during review.
Changes from v1:
* new patch, was not there in v1;
---
xen/common/cpupool.c |7 ---
xen/common/schedule.c | 31 ++-
2 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index e79850b..8e7b723 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -261,19 +261,13 @@ int cpupool_move_domain(struct domain *d, struct cpupool
*c)
static int cpupool_assign_cpu_locked(struct cpupool *c, unsigned int cpu)
{
int ret;
-struct cpupool *old;
struct domain *d;
if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
return -EBUSY;
-old = per_cpu(cpupool, cpu);
-per_cpu(cpupool, cpu) = c;
ret = schedule_cpu_switch(cpu, c);
if ( ret )
-{
-per_cpu(cpupool, cpu) = old;
return ret;
-}
cpumask_clear_cpu(cpu, &cpupool_free_cpus);
if (cpupool_moving_cpu == cpu)
@@ -326,7 +320,6 @@ static long cpupool_unassign_cpu_helper(void *info)
cpumask_clear_cpu(cpu, &cpupool_free_cpus);
goto out;
}
-per_cpu(cpupool, cpu) = NULL;
cpupool_moving_cpu = -1;
cpupool_put(cpupool_cpu_moving);
cpupool_cpu_moving = NULL;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 88e456f..1512d79 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1486,6 +1486,17 @@ void __init scheduler_init(void)
BUG();
}
+/*
+ * Move a pCPU outside of the influence of the scheduler of its current
+ * cpupool, or subject it to the scheduler of a new cpupool.
+ *
+ * For the pCPUs that are removed from their cpupool, their scheduler becomes
+ * &ops (the default scheduler, selected at boot, which also services the
+ * default cpupool). However, as these pCPUs are not really part of any pool,
+ * there won't be any scheduling event on them, not even from the default
+ * scheduler. Basically, they will just sit idle until they are explicitly
+ * added back to a cpupool.
+ */
int schedule_cpu_switch(unsigned int cpu, struct cpupool *c)
{
struct vcpu *idle;
@@ -1493,9 +1504,24 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool
*c)
void *ppriv, *ppriv_old, *vpriv, *vpriv_old;
struct scheduler *old_ops = per_cpu(scheduler, cpu);
struct scheduler *new_ops = (c == NULL) ? &ops : c->sched;
+struct cpupool *old_pool = per_cpu(cpupool, cpu);
+
+/*
+ * pCPUs only move from a valid cpupool to free (i.e., out of any pool),
+ * or from free to a valid cpupool. In the former case (which happens when
+ * c is NULL), we want the CPU to have been marked as free already, as
+ * well as to not be valid for the source pool any longer, when we get to
+ * here. In the latter case (which happens when c is a valid cpupool), we
+ * want the CPU to still be marked as free, as well as to not yet be valid
+ * for the destination pool.
+ */
+ASSERT(c != old_pool && (c != NULL || old_pool != NULL));
+ASSERT(cpumask_test_cpu(cpu, &cpupool_free_cpus));
+ASSERT((c == NULL && !cpumask_test_cpu(cpu, old_pool->cpu_valid)) ||
+ (c != NULL && !cpumask_test_cpu(cpu, c->cpu_valid)));
if ( old_ops == new_ops )
-return 0;
+goto out;
idle = idle_vcpu[cpu];
ppriv = SCHED_OP(new_ops, alloc_pdata, cpu);
@@ -1523,6 +1549,9 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool
*c)
SCHED_OP(old_ops, free_vdata, vpriv_old);
SCHED_OP(old_ops, free_pdata, ppriv_old, cpu);
+ out:
+per_cpu(cpupool, cpu) = c;
+
return 0;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 6/6] xen: sched: get rid of the per domain vCPU list in Credit2
As, curently, there is no reason for bothering having
it and keeping it updated.
In fact, it is only used for dumping and changing
vCPUs parameters, but that can be achieved easily with
for_each_vcpu.
While there, improve alignment of comments, ad
add a const qualifier to a pointer, making things
more consistent with what happens everywhere else
in the source file.
This also allows us to kill one of the remaining
FIXMEs in the code, which is always good.
Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
---
Cc: Andrew Cooper
---
Changes from v1:
* removed spurious hunk about sched_rt.c, as noted
during review;
* fixed the BUG_ON inside csched2_dom_destroy(), as
noted during review;
* used 'v' instead of 'vc' for 'vcpu' (in new code),
as suggested during review.
---
xen/common/sched_credit2.c | 34 +++---
1 file changed, 11 insertions(+), 23 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 556ca0f..3c49ffa 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -234,9 +234,8 @@ struct csched2_private {
* Virtual CPU
*/
struct csched2_vcpu {
-struct list_head rqd_elem; /* On the runqueue data list */
-struct list_head sdom_elem; /* On the domain vcpu list */
-struct list_head runq_elem; /* On the runqueue */
+struct list_head rqd_elem; /* On the runqueue data list */
+struct list_head runq_elem;/* On the runqueue*/
struct csched2_runqueue_data *rqd; /* Up-pointer to the runqueue */
/* Up-pointers */
@@ -261,7 +260,6 @@ struct csched2_vcpu {
* Domain
*/
struct csched2_dom {
-struct list_head vcpu;
struct list_head sdom_elem;
struct domain *dom;
uint16_t weight;
@@ -770,7 +768,6 @@ csched2_alloc_vdata(const struct scheduler *ops, struct
vcpu *vc, void *dd)
return NULL;
INIT_LIST_HEAD(&svc->rqd_elem);
-INIT_LIST_HEAD(&svc->sdom_elem);
INIT_LIST_HEAD(&svc->runq_elem);
svc->sdom = dd;
@@ -874,9 +871,6 @@ csched2_vcpu_insert(const struct scheduler *ops, struct
vcpu *vc)
BUG_ON(is_idle_vcpu(vc));
-/* FIXME: Do we need the private lock here? */
-list_add_tail(&svc->sdom_elem, &svc->sdom->vcpu);
-
/* Add vcpu to runqueue of initial processor */
lock = vcpu_schedule_lock_irq(vc);
@@ -921,10 +915,6 @@ csched2_vcpu_remove(const struct scheduler *ops, struct
vcpu *vc)
vcpu_schedule_unlock_irq(lock, vc);
-/* Remove from sdom list. Don't need a lock for this, as it's called
- * syncronously when nothing else can happen. */
-list_del_init(&svc->sdom_elem);
-
svc->sdom->nr_vcpus--;
}
}
@@ -1441,7 +1431,7 @@ csched2_dom_cntl(
if ( op->u.credit2.weight != 0 )
{
-struct list_head *iter;
+struct vcpu *v;
int old_weight;
old_weight = sdom->weight;
@@ -1449,9 +1439,9 @@ csched2_dom_cntl(
sdom->weight = op->u.credit2.weight;
/* Update weights for vcpus, and max_weight for runqueues on which
they reside */
-list_for_each ( iter, &sdom->vcpu )
+for_each_vcpu ( d, v )
{
-struct csched2_vcpu *svc = list_entry(iter, struct
csched2_vcpu, sdom_elem);
+struct csched2_vcpu *svc = CSCHED2_VCPU(v);
/* NB: Locking order is important here. Because we grab this
lock here, we
* must never lock csched2_priv.lock if we're holding a
runqueue lock.
@@ -1485,7 +1475,6 @@ csched2_alloc_domdata(const struct scheduler *ops, struct
domain *dom)
return NULL;
/* Initialize credit and weight */
-INIT_LIST_HEAD(&sdom->vcpu);
INIT_LIST_HEAD(&sdom->sdom_elem);
sdom->dom = dom;
sdom->weight = CSCHED2_DEFAULT_WEIGHT;
@@ -1537,9 +1526,7 @@ csched2_free_domdata(const struct scheduler *ops, void
*data)
static void
csched2_dom_destroy(const struct scheduler *ops, struct domain *dom)
{
-struct csched2_dom *sdom = CSCHED2_DOM(dom);
-
-BUG_ON(!list_empty(&sdom->vcpu));
+BUG_ON(CSCHED2_DOM(dom)->nr_vcpus > 0);
csched2_free_domdata(ops, CSCHED2_DOM(dom));
}
@@ -1879,7 +1866,7 @@ csched2_dump_pcpu(const struct scheduler *ops, int cpu)
static void
csched2_dump(const struct scheduler *ops)
{
-struct list_head *iter_sdom, *iter_svc;
+struct list_head *iter_sdom;
struct csched2_private *prv = CSCHED2_PRIV(ops);
unsigned long flags;
int i, loop;
@@ -1924,6 +1911,8 @@ csched2_dump(const struct scheduler *ops)
list_for_each( iter_sdom, &prv->sdom )
{
struct csched2_dom *sdom;
+struct vcpu *v;
+
sdom = list_entry(iter_sdom, struct csched2_dom, sdom_elem);
printk("\tDomain: %d w %d v %d\n",
@@ -1931,12 +1920,11 @@ csched2_dump(const struct scheduler *ops)
sdom->weight,
sdom->nr_vcpus);
-
[Xen-devel] [PATCH v4 0/6] xen: sched: fix locking of {insert, remove}_vcpu()
Hi, This series, improves how inserting vCPUs in schedulers runqueues is done, including fixing a couple of bugs, and paving the way for more improvement in Credit2 runqueue handling (will be submitted as a separate series). v3 is here: http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03278.html Message-Id: <20151029225158.25219.4625.stgit@Solace.station> Only patch 1 really changed from v3, and patches 1 and 2 are the only one that seem to me to be missing suitable Ack-s. There is a git branch for this series here: git://xenbits.xen.org/people/dariof/xen.git rel/sched/fix-vcpu-ins-rem-v4 Regards, Dario --- Dario Faggioli (6): xen: sched: fix locking of remove_vcpu() in credit1 xen: sched: fix locking for insert_vcpu() in credit1 and RTDS xen: sched: clarify use cases of schedule_cpu_switch() xen: sched: better handle (not) inserting idle vCPUs in runqueues xen: sched: get rid of the per domain vCPU list in RTDS xen: sched: get rid of the per domain vCPU list in Credit2 xen/common/cpupool.c |7 - xen/common/sched_credit.c | 18 - xen/common/sched_credit2.c | 55 ++-- xen/common/sched_rt.c | 61 ++-- xen/common/schedule.c | 57 +++-- 5 files changed, 103 insertions(+), 95 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
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
set_xen_guest_handle_raw"):
> On 04.11.15 at 17:50, wrote:
> > If we don't provide a get_xen_guest_handle, a kernel developer will be
> > sorely tempted to make one.
>
> What use would it be to them? Kernels only write handles, they
> shouldn't have a need for reading them.
I foresee situations where a kernel might like to update a proposed
hypercall argument structure in place, which might involve reading the
handles.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
>>> On 04.11.15 at 17:50, wrote:
> Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
> set_xen_guest_handle_raw"):
>> All quite interesting, but pretty moot with there not being any
>> get_xen_guest_handle() anymore.
>
> If we don't provide a get_xen_guest_handle, a kernel developer will be
> sorely tempted to make one.
What use would it be to them? Kernels only write handles, they
shouldn't have a need for reading them.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [V9 1/3] x86/xsaves: enable xsaves/xrstors/xsavec in xen
>>> On 03.11.15 at 07:27, wrote:
> This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor
> to perform the xsave_area switching so that xen itself
> can benefit from them when available.
>
> For xsaves/xrstors/xsavec only use compact format. Add format conversion
> support when perform guest os migration.
>
> Also, pv guest will not support xsaves/xrstors.
>
> Signed-off-by: Shuai Ruan
> ---
> xen/arch/x86/domain.c| 7 ++
> xen/arch/x86/domctl.c| 30 +-
> xen/arch/x86/hvm/hvm.c | 18 +++-
> xen/arch/x86/i387.c | 4 +
> xen/arch/x86/traps.c | 6 +-
> xen/arch/x86/xstate.c| 242
> +--
> xen/include/asm-x86/xstate.h | 2 +
> 7 files changed, 265 insertions(+), 44 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index fe3be30..108d4f8 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -883,7 +883,12 @@ int arch_set_info_guest(
> {
> memcpy(v->arch.fpu_ctxt, &c.nat->fpu_ctxt, sizeof(c.nat->fpu_ctxt));
> if ( v->arch.xsave_area )
> +{
> v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
> + if ( cpu_has_xsaves || cpu_has_xsavec )
> + v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE |
> +
> XSTATE_COMPACTION_ENABLED;
> +}
So here you nicely extend the existing conditional.
> @@ -1568,6 +1573,8 @@ static void __context_switch(void)
> if ( xcr0 != get_xcr0() && !set_xcr0(xcr0) )
> BUG();
> }
> +if ( cpu_has_xsaves && has_hvm_container_vcpu(n) )
> +set_msr_xss(n->arch.hvm_vcpu.msr_xss);
Why not also here (the previous if() uses cpu_has_xsave, which
you surely depend on)? Agreed the difference is minor for modern
CPUs, but I wanted to ask anyway. I.e. an explanation will do,
no need to re-submit just because of this.
> @@ -158,6 +334,20 @@ void xsave(struct vcpu *v, uint64_t mask)
> ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] = word_size;
> }
>
> +#define XSTATE_FIXUP ".section .fixup,\"ax\" \n"\
> + "2: mov %5,%%ecx \n"\
> + " xor %1,%1\n"\
> + " rep stosb\n"\
> + " lea %2,%0\n"\
> + " mov %3,%1\n"\
> + " jmp 1b \n"\
> + ".previous \n"\
> + _ASM_EXTABLE(1b, 2b)\
> + : "+&D" (ptr), "+&a" (lmask)\
> + : "m" (*ptr), "g" (lmask), "d" (hmask), \
> + "m" (xsave_cntxt_size)\
> + : "ecx"
> +
> void xrstor(struct vcpu *v, uint64_t mask)
> {
> uint32_t hmask = mask >> 32;
> @@ -187,39 +377,22 @@ void xrstor(struct vcpu *v, uint64_t mask)
> switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) )
> {
> default:
> -asm volatile ( "1: .byte 0x48,0x0f,0xae,0x2f\n"
> - ".section .fixup,\"ax\" \n"
> - "2: mov %5,%%ecx \n"
> - " xor %1,%1\n"
> - " rep stosb\n"
> - " lea %2,%0\n"
> - " mov %3,%1\n"
> - " jmp 1b \n"
> - ".previous \n"
> - _ASM_EXTABLE(1b, 2b)
> - : "+&D" (ptr), "+&a" (lmask)
> - : "m" (*ptr), "g" (lmask), "d" (hmask),
> - "m" (xsave_cntxt_size)
> - : "ecx" );
> +alternative_input("1: "".byte 0x48,0x0f,0xae,0x2f",
> + ".byte 0x48,0x0f,0xc7,0x1f",
> + X86_FEATURE_XSAVES,
> + "D" (ptr), "m" (*ptr), "a" (lmask), "d" (hmask));
> +asm volatile (XSTATE_FIXUP);
> break;
> case 4: case 2:
> -asm volatile ( "1: .byte 0x0f,0xae,0x2f\n"
> - ".section .fixup,\"ax\" \n"
> - "2: mov %5,%%ecx\n"
> - " xor %1,%1 \n"
> - " rep stosb \n"
> - " lea %2,%0 \n"
> - " mov %3,%1 \n"
> - " jmp 1b \n"
> - ".previous \n"
> - _ASM_EXTABLE(1b, 2b)
> - : "+&D" (ptr), "+&a" (lmask)
> - : "m" (*ptr), "g" (lmask), "d"
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
On 04/11/15 16:50, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
> set_xen_guest_handle_raw"):
>> All quite interesting, but pretty moot with there not being any
>> get_xen_guest_handle() anymore.
>
> If we don't provide a get_xen_guest_handle, a kernel developer will be
> sorely tempted to make one.
>
> If they do and they write it in the obvious way, then the compiler
> could `deduce' that the top part of the uint64_t store was dead, and
> eliminate it.
The developers could also decide to rewrite the
set_xen_raw_guest_handle/get_xen_guest_handle in an obvious way because
they think ours it's too complicate... See the Linux version.
TBH, we can't protect ourself for a developer writing it own macro and
don't think about the big picture. The comment in the header pretty much
explain the constraint. If it doesn't read, well it's not our business.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH v15] Nested HVM
Ian Jackson writes ("[OSSTEST PATCH v14 PART 1 0/9] Nested HVM preparation
patches"):
> This is the first part of Robert Hu's osstest patch series to support
> nested HVM tests. (v13 was passed to me as a git branch `under the
> table' by Robert.) I have rewritten the commit messages, refactored a
> few patches, and reordered the series slightly.
Robert has passed me a tentative version of v15 via `git bundle'. I
have made it available here:
http://xenbits.xen.org/gitweb/?p=people/iwj/osstest.git;a=shortlog;h=refs/heads/wip.nested-v15
I'm going to fold in the fixup!s, review it, and probably adjust it
somewhat. I will call the result v16, even though I am not sending a
v15 patchbomb to the list.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
set_xen_guest_handle_raw"):
> All quite interesting, but pretty moot with there not being any
> get_xen_guest_handle() anymore.
If we don't provide a get_xen_guest_handle, a kernel developer will be
sorely tempted to make one.
If they do and they write it in the obvious way, then the compiler
could `deduce' that the top part of the uint64_t store was dead, and
eliminate it.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
>>> On 04.11.15 at 17:22, wrote:
> Julien Grall writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
> set_xen_guest_handle_raw"):
>> On 03/11/15 14:18, Stefano Stabellini wrote:
>> >> +#define set_xen_guest_handle_raw(hnd, val) \
>> >> +do {\
>> >> +/* Check if the handle is 64-bit (i.e 8-byte) */\
>> >> +(void) sizeof(struct { int : -!!(sizeof (hnd) != 8); });\
>> >> +/* Check if the type of val is compatible with the handle */\
>> >> +(void) sizeof((val) != (hnd).p);\
>> >> +(hnd).q = (uint64_t)(uintptr_t)(val); \
>> >> } while ( 0 )
>> >> #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
>
> I hate to throw yet more variables into this, but I had a discussion
> with some C experts in the pub about this problem. Further thought
> (including a red herring where someone suggested that memcpy would
> "launder" the types) results in this proposal:
>
>
> union xen_guest_handle_TYPE {
> TYPE *p;
> uint64_t align;
> };
>
> struct xen_guest_handle__pointer {
> uint8_t p0,p1,p2,p3;
> };
>
> /*
> * void set_xen_guest_handle_raw(xen_guest_handle_TYPE *hnd, TYPE *val);
> */
> #define set_xen_guest_handle_raw(hnd, val)
> do {
> void *copy = (val);
> struct xen_guest_handle__pointer *src = &(hnd);
> struct xen_guest_handle__pointer *dst = &(xen_xgh_copy);
> dst->p0 = src->p0;
> dst->p1 = src->p1;
> dst->p2 = src->p2;
> dst->p3 = src->p3;
> dst[1]->p0 = 0;
> dst[1]->p1 = 0;
> dst[1]->p2 = 0;
> dst[1]->p3 = 0;
> sizeof((hnd).p == (val)); /* typecheck */
> }
>
> #define get_xen_guest_handle(hnd) ((hnd).p)
>
>
> The above is legal for the following reasons (C99 6.5):
>
> Considering the accesses to src and dst. These are legal according to
> (7) point 5. (Accesses via a character type are always legal.)
>
> After the above macro has been used to set, what is the effective type
> of hnd for a subsequent get_xen_guest_handle ?
All quite interesting, but pretty moot with there not being any
get_xen_guest_handle() anymore.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 63532: tolerable FAIL - PUSHED
flight 63532 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/63532/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 63437 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 63437 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 63437 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 63437 test-amd64-amd64-xl-rtds 6 xen-boot fail like 63437 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-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-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass version targeted for testing: xen e0a36c028bd6d9f50982bc2eaacadc0036267e27 baseline version: xen 423d2cd814e8460d5ea8bd191a770f3c48b3947c Last test of basis63437 2015-11-01 07:11:06 Z3 days Testing same since63532 2015-11-03 09:43:38 Z1 days1 attempts People who touched revisions under test: Jan Beulich jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass 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 test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
Ian Jackson writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
set_xen_guest_handle_raw"):
> void *copy = (val);
> struct xen_guest_handle__pointer *src = &(hnd);
> struct xen_guest_handle__pointer *dst = &(xen_xgh_copy);
I have my src and dst the wrong way round, and have used the a
variable name from a previous draft. This should be:
> struct xen_guest_handle__pointer *src = &(copy);
> struct xen_guest_handle__pointer *dst = &(hnd);
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
Julien Grall writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro
set_xen_guest_handle_raw"):
> On 03/11/15 14:18, Stefano Stabellini wrote:
> >> +#define set_xen_guest_handle_raw(hnd, val) \
> >> +do {\
> >> +/* Check if the handle is 64-bit (i.e 8-byte) */\
> >> +(void) sizeof(struct { int : -!!(sizeof (hnd) != 8); });\
> >> +/* Check if the type of val is compatible with the handle */\
> >> +(void) sizeof((val) != (hnd).p);\
> >> +(hnd).q = (uint64_t)(uintptr_t)(val); \
> >> } while ( 0 )
> >> #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
I hate to throw yet more variables into this, but I had a discussion
with some C experts in the pub about this problem. Further thought
(including a red herring where someone suggested that memcpy would
"launder" the types) results in this proposal:
union xen_guest_handle_TYPE {
TYPE *p;
uint64_t align;
};
struct xen_guest_handle__pointer {
uint8_t p0,p1,p2,p3;
};
/*
* void set_xen_guest_handle_raw(xen_guest_handle_TYPE *hnd, TYPE *val);
*/
#define set_xen_guest_handle_raw(hnd, val)
do {
void *copy = (val);
struct xen_guest_handle__pointer *src = &(hnd);
struct xen_guest_handle__pointer *dst = &(xen_xgh_copy);
dst->p0 = src->p0;
dst->p1 = src->p1;
dst->p2 = src->p2;
dst->p3 = src->p3;
dst[1]->p0 = 0;
dst[1]->p1 = 0;
dst[1]->p2 = 0;
dst[1]->p3 = 0;
sizeof((hnd).p == (val)); /* typecheck */
}
#define get_xen_guest_handle(hnd) ((hnd).p)
The above is legal for the following reasons (C99 6.5):
Considering the accesses to src and dst. These are legal according to
(7) point 5. (Accesses via a character type are always legal.)
After the above macro has been used to set, what is the effective type
of hnd for a subsequent get_xen_guest_handle ?
If hnd is an object with a declared type (ie, an actual variable,
function parameter, or whatever, rather than from malloc), then the
effective type is that of hnd, so the effective type is the union, and
the effective type of hnd.p is TYPE*.
If hnd is not a declared object, then the effective type might be set
by one of the stores in (6): store through an non-character lvalue;
copy via memcpy or memmove; copy as `an array of character type'.
But we store only through character lvalues. We do not store with
memcpy or memmove. We do not copy as an array, but as a struct.
So none of the rules defining the effective type apply. We are left
with the fallback: the effective type of the subsequent read is the
type used for access.
So a subsequent get's read of hnd.p is legal.
With luck the compiler's optimiser will eliminate the temporaries and
aggregate the byte-wide stores.
In the actual macro all of the struct and union fields and all of the
temporary variables should be prefixed with `xen_xgh_' or some such,
in case the calling code has (arguably foolishly) #defined src or dst
or p or something.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 16/32] xen/x86: allow disabling the pmtimer
>>> On 04.11.15 at 17:05, wrote: > El 03/11/15 a les 13.41, Jan Beulich ha escrit: > On 03.11.15 at 11:57, wrote: >>> On 03/11/15 07:21, Jan Beulich wrote: >>> On 30.10.15 at 16:36, wrote: > On 30/10/15 13:16, Jan Beulich wrote: > On 30.10.15 at 13:50, wrote: >>> El 14/10/15 a les 16.37, Jan Beulich ha escrit: >>> On 02.10.15 at 17:48, wrote: > Signed-off-by: Roger Pau Monné > Cc: Jan Beulich > Cc: Andrew Cooper > --- > Changes since v6: > - Return ENODEV in pmtimer_load if the timer is disabled. > - hvm_acpi_power_button and hvm_acpi_sleep_button become noops if the >pmtimer is disabled. But how are those two features connected? I don't think you can assume absence of a PM block just because there's no PM timer. Or if you want to tie them together for now, the predicate needs to be renamed. > - Return ENODEV if pmtimer_change_ioport is called with the pmtimer >disabled. Same here. >>> What about changing XEN_X86_EMU_PMTIMER into XEN_X86_EMU_PM and this >>> flags disables all PM stuff? >> Ah, right, that's a reasonable option. > It still might be a nice idea to split them in two, given future work. > > To support hotplug properly (cpu, ram and pci), Xen needs to inject > GPEs, which comes from part of the PM infrastructure. To support PCI > devices in the future without the whole PM infrastructure, it would be > nice to keep the split. Coming back to this - I'm not sure: The hotplug aspect as you mention it should matter for Dom0 only. DomU could (and perhaps should) use a PV interface instead. >>> >>> I disagree. >>> >>> All PVH guests should use the same mechanism; making a split between >>> dom0 and domU will only make our lives harder. >>> >>> Where reasonable, we should follow what happens on native; one of the >>> underlying points of PVH is to have less of an impact on the guest >>> side. In some cases it is indeed nasty, but has the advantage of being >>> well understood. >> >> What meaning would ACPI have to a PVH DomU? >> So I'd like to suggest quite the opposite: Don't call the thing PM, but make it more general and call it ACPI. And instead of separating HPET, we might have this fall under ACPI as well, or we might have a second TIMER flag, requiring both to be set for there to be a HPET and PMTMR. This leaves open the option of Dom0 getting ACPI enabled (despite this then being "real", not emulated ACPI), but TIMER left off. >>> >>> An HPET can exist independently of other features such as ACPI. It >>> should have its own option. >> >> Without ACPI there's no defined way to discover it. Doing what >> Linux does - applying chipset knowledge - won't work on PVH either, >> because there's no emulated chipset. Which would leave scanning >> physical memory, but if there is none, none can be found. >> >>> +1 to having an ACPI option, but as indicated above, I expect it to be >>> used in the longterm even for domU. >> >> Again - why and how? > > I think that at this point in the design it's not so important to have > all the XEN_X86_EMU_* properly defined. This is not a public interface, > so we can expand/reduce them whenever we want. Would it be fine, for the > time being to just have a XEN_X86_EMU_PM and control both the PM and the > PMTMR? I think so, yes. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] (XEN) APIC error on CPU0: 40(00)
>>> On 04.11.15 at 16:15, wrote: > Hi, > i just build the latest 4.3.0 kernel and ran it on qubes-os with xen > 4.4.3. I get this error just before the reboot: > > [(XEN) APIC error on CPU0: 40(00) And this appeared with the switch to kernel 4.3? No other variable (e.g. all config options new in 4.3 turned off)? I ask because the APIC is driven by Xen, not the kernel, and hence the kernel should have no (direct) influence on APIC behavior. > (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. > > I can also see some weird acpi-related messages on the log i attached, like: > (XEN) ACPI: Invalid sleep control/status register data: 0:0x8:0x3 0:0x8:0x3 > (XEN) ERST table was not found > [3.608404] ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup > failure, AE_NOT_FOUND (20150818/dswload-210) > [3.608410] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog > (20150818/psobject-227) > [3.608439] ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) while > loading table (20150818/tbxfload-193) > [3.619914] ACPI Error: 1 table load failures, 5 successful > (20150818/tbxfload-214) > [3.679113] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored > [3.688942] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep > State [\_S1_] (20150818/hwxface-580) > [3.688948] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep > State [\_S2_] (20150818/hwxface-580) > [3.756027] PM-Timer failed consistency check (0xff) - aborting. > > With older kernels (like 3.12 or 4.2.1) i always see those messages but > i'm able to boot without the acpi error. I guess those latter messages are unrelated - not the difference between ACPI and APIC. Also I'm unsure about you saying "boot" here but "reboot" above? > My machine runs on skylake cpu with z170 chipset and the latest bios. > Any ideas on how to fix this? Not without first figuring out what bad vector is being received by the APIC, which likely will involved quite a bit of debugging and code instrumentation. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
On 11/04/2015 06:55 AM, Sander Eikelenboom wrote: Hi All, I just tried to boot with the current linus mergewindow tree under Xen. It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX" option enabled. Disabling it makes the kernel boot fine. The splat: [ 18.424241] Freeing unused kernel memory: 1104K (822fc000 - 8241) [ 18.430314] Write protecting the kernel read-only data: 18432k [ 18.441054] Freeing unused kernel memory: 1144K (880001ae2000 - 880001c0) [ 18.447966] Freeing unused kernel memory: 1560K (88000207a000 - 88000220) [ 18.453947] BUG: unable to handle kernel paging request at 88055c883000 [ 18.459943] IP: [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.465847] PGD 2212067 PUD 0 [ 18.471564] Oops: [#1] SMP [ 18.477248] Modules linked in: [ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.3.0-mw-20151104-linus-doflr+ #1 [ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 18.494778] task: 880059b9 ti: 880059b98000 task.ti: 880059b98000 [ 18.500852] RIP: e030:[] [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.507102] RSP: e02b:880059b9be48 EFLAGS: 00010296 [ 18.513351] RAX: 88055c883000 RBX: 81ae2000 RCX: 8800 [ 18.519733] RDX: 0067 RSI: 880059b9be98 RDI: 88001000 [ 18.526129] RBP: 880059b9bf00 R08: R09: [ 18.532522] R10: 88005fd0e790 R11: 0001 R12: 88008000 [ 18.538891] R13: cfff R14: 880059b9be98 R15: [ 18.545247] FS: () GS:88005f68() knlGS: [ 18.551708] CS: e033 DS: ES: CR0: 8005003b [ 18.558153] CR2: 88055c883000 CR3: 02211000 CR4: 0660 [ 18.564686] Stack: [ 18.571106] 000159b9be50 82211000 88055c884000 0800 [ 18.577704] 8000 88055c883000 0007 88005fd0e790 [ 18.584291] 880059b9bed8 81156ace 0001 [ 18.590916] Call Trace: [ 18.597458] [] ? free_reserved_area+0x11e/0x120 [ 18.604180] [] ptdump_walk_pgd_level_checkwx+0x12/0x20 [ 18.611014] [] mark_rodata_ro+0xe9/0xf0 [ 18.617819] [] ? rest_init+0x80/0x80 [ 18.624512] [] kernel_init+0x18/0xe0 [ 18.631095] [] ret_from_fork+0x3f/0x70 [ 18.637650] [] ? rest_init+0x80/0x80 [ 18.644178] Code: 70 ff ff ff 48 3b 85 58 ff ff ff 0f 84 c0 fe ff ff 48 8b 85 68 ff ff ff 48 c1 e0 10 48 c1 f8 10 48 89 45 b0 48 8b 85 70 ff ff ff <48> 8b 38 48 85 ff 0f 85 4e ff ff ff b9 02 00 00 00 31 d2 4c 89 [ 18.658246] RIP [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.665211] RSP [ 18.672073] CR2: 88055c883000 [ 18.678852] ---[ end trace d84e34461c40637a ]--- [ 18.685641] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [ 18.685641] [ 18.699520] Kernel Offset: disable What's your .config? Does cat /sys/kernel/debug/kernel_page_tables produce a similar fault even with CONFIG_DEBUG_WX=n? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH XEN v4 07/23] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab.
On Thu, 2015-10-29 at 16:28 +, Wei Liu wrote:
> On Wed, Oct 21, 2015 at 04:23:14PM +0100, Ian Campbell wrote:
> > libxengnttab will provide a stable API and ABI for accessing the
> > grant table devices.
> >
> > The functions are moved into the xengnt{tab,shr} namespace to make a
> > clean break from libxc and avoid ambiguity regarding which interfaces
> > are stable.
> >
> > XXX consider combining into a single namespace (i.e. with
> > xengnttab_handle having two open fd's in it on Linux)
> >
>
> This?
Currently there are two separate interfaces (i.e. 2x_open, 2x handle types,
2x sets of functions for using the handle, 2x namespaces, etc) in this
library corresponding to two underlying devices in /dev/xen, one of which
is for utilising grant references which you have been given (gntdev), the
other of which is for allocating suitable memory for granting and creating
grants of it to give away to others (gntshr).
Only Linux and mini-os implement gntshr today, I think.
AFAIK most consumers (e.g. qemu's pv backends, or userspace pv backends
generally) are only using the first (consuming grants). The only user of
gntshr I know of is libvchan, but in general any userspace frontend would
likely need this functionality.
There are three possibilities here for the stable library interface:
* Do nothing, keep it as two interfaces in one library.
* Split into separate libgntdev and libgntshr libraries.
* Unify the two APIs such that a single handle actually contains two fd's
and functions are all in the same namespace etc and just the correct
underlying fd associated with the op.
The comment is wondering if we should do the third, I hadn't thought of the
middle one at the time.
Right now my preference is towards the first, the implementation of which
is "delete the XXX comment".
The downside of not merging is that if some new OS port comes along which
has gntdev and gntshr in a single device that the applications then still
have to open and manage two handles and updating the ABI to unify them
later would be a pain.
I'm inclined towards lazily thinking that having two handles is not such a
big deal, even on an OS where the underlying implementation is such that
they contain "redundant" file handles.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1] xen/serial: Return actual bytes stored in TX FIFO for OMAP
On Tue, Nov 3, 2015 at 6:36 PM, Ian Campbell wrote: > On Tue, 2015-10-27 at 10:40 -0600, Jan Beulich wrote: >> > > > On 27.10.15 at 17:32, wrote: >> > And what are you suggesting about the patch? Create a separate OMAP >> > specific header? >> >> For #define-s used by only a single source file I'd suggest putting >> them into the source file instead of into a (shared) header. > > I agree. (Any to be clear, any existing OMAP specific things in 8250,h > should move too). OK. I will take it into account. Thank you > > Ian. > -- Oleksandr Tyshchenko | Embedded Dev GlobalLogic www.globallogic.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 16/32] xen/x86: allow disabling the pmtimer
El 03/11/15 a les 13.41, Jan Beulich ha escrit: On 03.11.15 at 11:57, wrote: >> On 03/11/15 07:21, Jan Beulich wrote: >> On 30.10.15 at 16:36, wrote: On 30/10/15 13:16, Jan Beulich wrote: On 30.10.15 at 13:50, wrote: >> El 14/10/15 a les 16.37, Jan Beulich ha escrit: >> On 02.10.15 at 17:48, wrote: Signed-off-by: Roger Pau Monné Cc: Jan Beulich Cc: Andrew Cooper --- Changes since v6: - Return ENODEV in pmtimer_load if the timer is disabled. - hvm_acpi_power_button and hvm_acpi_sleep_button become noops if the pmtimer is disabled. >>> But how are those two features connected? I don't think you can >>> assume absence of a PM block just because there's no PM timer. >>> Or if you want to tie them together for now, the predicate needs >>> to be renamed. >>> - Return ENODEV if pmtimer_change_ioport is called with the pmtimer disabled. >>> Same here. >> What about changing XEN_X86_EMU_PMTIMER into XEN_X86_EMU_PM and this >> flags disables all PM stuff? > Ah, right, that's a reasonable option. It still might be a nice idea to split them in two, given future work. To support hotplug properly (cpu, ram and pci), Xen needs to inject GPEs, which comes from part of the PM infrastructure. To support PCI devices in the future without the whole PM infrastructure, it would be nice to keep the split. >>> Coming back to this - I'm not sure: The hotplug aspect as you >>> mention it should matter for Dom0 only. DomU could (and perhaps >>> should) use a PV interface instead. >> >> I disagree. >> >> All PVH guests should use the same mechanism; making a split between >> dom0 and domU will only make our lives harder. >> >> Where reasonable, we should follow what happens on native; one of the >> underlying points of PVH is to have less of an impact on the guest >> side. In some cases it is indeed nasty, but has the advantage of being >> well understood. > > What meaning would ACPI have to a PVH DomU? > >>> So I'd like to suggest quite the opposite: Don't call the thing PM, >>> but make it more general and call it ACPI. And instead of >>> separating HPET, we might have this fall under ACPI as well, or >>> we might have a second TIMER flag, requiring both to be set >>> for there to be a HPET and PMTMR. This leaves open the option >>> of Dom0 getting ACPI enabled (despite this then being "real", >>> not emulated ACPI), but TIMER left off. >> >> An HPET can exist independently of other features such as ACPI. It >> should have its own option. > > Without ACPI there's no defined way to discover it. Doing what > Linux does - applying chipset knowledge - won't work on PVH either, > because there's no emulated chipset. Which would leave scanning > physical memory, but if there is none, none can be found. > >> +1 to having an ACPI option, but as indicated above, I expect it to be >> used in the longterm even for domU. > > Again - why and how? I think that at this point in the design it's not so important to have all the XEN_X86_EMU_* properly defined. This is not a public interface, so we can expand/reduce them whenever we want. Would it be fine, for the time being to just have a XEN_X86_EMU_PM and control both the PM and the PMTMR? Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
On Wed, 2015-11-04 at 15:46 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework
> the macro set_xen_guest_handle_raw"):
> > The writer via one is the guest and reader via the other is the
> > hypervisor,
> > so no matter what they are certainly different compilation units, even
> > in
> > the face of whole program optimisations.
>
> The question of them being different `compilation units' (YM
> translation units) is irrelevant I think.
>
> > The concerning issue is that if the compiler can observe you writing to
> > both halves of the union then it can either omit the first write or
> > dive
> > off into deep undefined behaviour territory.
>
> If the compiler can see you write to p, it is allowed to assume that
> all subsequent readers will read the object as typeof(p). Reading
> typeof(p) does not read the padding. Therefore the compiler is
> allowed to `prove' that the padding is a dead store, and remove the
> write to the padding.
>
> This applies even if the compiler can't see the code which is doing
> the reading.
Ah, yes :-(
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] xen: sched: fix locking for insert_vcpu() in credit1 and RTDS
On Wed, 2015-11-04 at 10:01 -0500, Meng Xu wrote:
> 2015-11-04 9:12 GMT-05:00 Dario Faggioli :
> > Just FTR (and for next time :-D), is the above something that can
> > be
> > interpreted as a 'Reviewed-by: Meng Xu ' ? If no (e.g.,
> > because
> > you haven't looking thoroughly enough to feel confident to express
> > it),
> > then fine, I was just asking.
> Thank you very much for explaining this for me. :-)
>
> I feel confident about the changes for RTDS scheduler.
>
Ok.
> I'm not so confident about the change in the schedule.c. To be
> specific, this patch removes insert_vcpu in schedule_cpu_switch() in
> schedule.c;
>
It removes the attempt of inserting the idle vCPU in the runqueue of
the scheduler of the target cpupool for the pCPU.
More specifically, this line:
SCHED_OP(new_ops, insert_vcpu, idle);
If we look at the various ways in which insert_vcpu is implemented, we
have:
csched_vcpu_insert:
if ( !__vcpu_on_runq(svc) && vcpu_runnable(vc) && !vc->is_running )
__runq_insert(vc->processor, svc);
but the pCPU being switched is free, i.e., it is not in any cpupool,
and it is idling. So, the idle vCPU is running, and the condition above
is false, which means __runq_insert() is not really called.
csched2_vcpu_insert:
if ( ! is_idle_vcpu(vc) )
{
...
}
so trying to insert the idle vCPU is actually a nop.
rt_vcpu_insert:
if ( is_idle_vcpu(vc) )
return;
a nop again.
My point being that this patch actually removes nothing but a bunch of
if()-s, with no effect at all.
> I'm not so sure if it is ok to insert_vcpu when a domain is moved.
>
Hopefully, I addressed your doubts.
BTW, we're not talking about a domain being moved between pools. That
is done with another function. schedule_cpu_switch() is about taking a
pCPU off from a cpupool, or assigning a pCPU to cpupool.
> (Next time, I will stand out and ask although it may be a stupid
> question. ;-) )
>
Sure! And this does not look a stupid question to me. :-)
> So as to this patch, I will say:
> As far as the RTDS scheduler is concerned: Reviewed-by: Meng Xu <
> men...@cis.upenn.edu>
>
Ok, I haven't sent v4 yet, so I'll apply it there. Thanks.
Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
Ian Campbell writes ("Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the
macro set_xen_guest_handle_raw"):
> The writer via one is the guest and reader via the other is the hypervisor,
> so no matter what they are certainly different compilation units, even in
> the face of whole program optimisations.
The question of them being different `compilation units' (YM
translation units) is irrelevant I think.
> The concerning issue is that if the compiler can observe you writing to
> both halves of the union then it can either omit the first write or dive
> off into deep undefined behaviour territory.
If the compiler can see you write to p, it is allowed to assume that
all subsequent readers will read the object as typeof(p). Reading
typeof(p) does not read the padding. Therefore the compiler is
allowed to `prove' that the padding is a dead store, and remove the
write to the padding.
This applies even if the compiler can't see the code which is doing
the reading.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
Ian Jackson writes ("Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the
macro set_xen_guest_handle_raw"):
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 4/4] xen/public: arm:
> rework the macro set_xen_guest_handle_raw"):
> > Finally, based on the defect report #283 [2], the behavior of writing
> > from one member and reading from another is not clear.
>
> Because the hypervisor is compiled with -fno-strict-aliasing.
Incidentally, it is _necessary_ to write to the uint64_t last. C99
6.2.6.1(5) says that if you write to the 32-bit pointer, the upper
bits (corresponding to the uint64 but not part of the pointer) take on
unspecified values.
So writing the 32-bit pointer always invalidates the top bits, so if
you write to the uint64_t first, the 32-bit write makes the 64-bit
write a dead store.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [CALL-FOR-AGENDA] Monthly Xen.org Technical Call (2015-11-11)
The next Xen technical call will be at: Wed 11 Nov 17:00:00 GMT 2015 `date -d @1447261200` See http://lists.xen.org/archives/html/xen-devel/2015-01/msg00414.html for more information on the call. Please let me know (CC-ing the list) any topics which you would like to discuss. It might be useful to include: * References to any relevant/recent mailing list threads; * Other people who you think should be involved in the discussion (and CC them); If you would like to attend then please let me know so I can send you the dial in details. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] xl: log an error if libxl_cpupool_destroy() fails
On Wed, 2015-11-04 at 11:48 +0100, Dario Faggioli wrote: > In fact, right now, failing at destroying a cpupool is just > not reported to the user in any explicit way. > > Let's log an error, as it is customary for xl in these cases. > > Signed-off-by: Dario Faggioli > Reviewed-by: Juergen Gross > Acked-by: Wei Liu Applied (cleanly) thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xl: avoid (another) uninitialised use of rc in vcpuset()
On Wed, 2015-11-04 at 13:03 +0100, Dario Faggioli wrote:
> Rearange the case when we check the new number of vCPUs
> against the number of host pCPUs not to use rc for internal
> error reporting. In fact:
> - rc was at risk of being used uninitialised;
> - rc should only be used for holding libxl error codes.
>
> Signed-off-by: Dario Faggioli
acked + applied.
> ---
> Cc: Ian Campbell
> Cc: Ian Jackson
> Cc: Wei Liu
> Cc: Harmandeep Kaur
> Cc: Andrew Cooper
> ---
> tools/libxl/xl_cmdimpl.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 9b6b42c..78048a1 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -5457,21 +5457,21 @@ static int vcpuset(uint32_t domid, const char*
> nr_vcpus, int check_host)
> * by the host's amount of pCPUs.
> */
> if (check_host) {
> -unsigned int host_cpu = libxl_get_max_cpus(ctx);
> +unsigned int online_vcpus, host_cpu = libxl_get_max_cpus(ctx);
> libxl_dominfo dominfo;
>
> if (libxl_domain_info(ctx, &dominfo, domid))
> return 1;
>
> -if (max_vcpus > dominfo.vcpu_online && max_vcpus > host_cpu) {
> +online_vcpus = dominfo.vcpu_online;
> +libxl_dominfo_dispose(&dominfo);
> +
> +if (max_vcpus > online_vcpus && max_vcpus > host_cpu) {
> fprintf(stderr, "You are overcommmitting! You have %d
> physical" \
> " CPUs and want %d vCPUs! Aborting, use --ignore-
> host to" \
> " continue\n", host_cpu, max_vcpus);
> -rc = 1;
> -}
> -libxl_dominfo_dispose(&dominfo);
> -if (rc)
> return 1;
> +}
> }
> rc = libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus);
> if (rc) {
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xenconsoled: Remove unexpected daemonize behavior
On Tue, 2015-11-03 at 17:20 +, Wei Liu wrote: > Acked-by: Wei Liu Applied w/ this + Ian J's ack. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
On Wed, 2015-11-04 at 15:19 +, Stefano Stabellini wrote:
> On Wed, 4 Nov 2015, Julien Grall wrote:
> > On 04/11/15 11:27, Ian Campbell wrote:
> > > On Wed, 2015-11-04 at 11:17 +, Julien Grall wrote:
> > > > >
> > > > > we could:
> > > > > #ifdef(__XEN__)
> > > > > #define XEN_BUILD_BUG_ON(x) BUILD_BUG_ON(x)
> > > > > #elif !defined(XEN_BUILD_BUG_ON)
> > > > > #define XEN_BUILD_BUG_ON(x)
> > > > > #endif
> > > > > and using XEN_BUILD_BUG_ON in the macro
> > > > >
> > > > > So, __XEN__ builds get the check and users can opt in by
> > > > > providing
> > > > > XEN_BUILD_BUG_ON if they want. If they don't then they don't get
> > > > > the
> > > > > check.
> > > >
> > > > I wouldn't let the user the choice to disable build-time check.
> > >
> > > Up to you. Note that "the user" here would potentially include
> > > xen.git/tools, and I would expect them to want to define it.
> > >
> > > Also...
> > >
> > > > There is
> > > > no harm to open-code them as I did today and avoid possible issue
> > > > in the
> > > > code later.
> > >
> > > ... there is always a downside to open coding. If you don't want to
> > > expose
> > > the ability to define a BUG_ON to the application then just drop that
> > > #elif
> > > from the chain.
> >
> > Good point. I will give a look.
> >
> > >
> > > > > Or maybe we could just omit this from the public API by one or
> > > > > both of
> > > > > a)
> > > > > adding an explicit 8 byte type to the union purely to force the
> > > > > size
> > > > > and/or
> > > >
> > > > This is already done in the current version:
> > > >
> > > > typedef union { type *p; uint64_aligned_t q; } \
> > > > __guest_handle_64_ ## name;
> > > >
> > > > However I don't see how this ensure that the caller of
> > > > set_xen_raw_guest_handle will effectively hnd as a pointer to an 8-
> > > > byte
> > > > placeholder.
> > >
> > > Not sure I follow. If hnd isn't a suitable struct xen guest handle
> > > then
> > > other things will fail. If a user is passing a non struct
> > > xen_guest_handle
> > > to this which happens to contain the same fields then more fool them,
> > > and
> > > if it happens to be 8 bytes anyway your check won't catch that.
> >
> > With the 2 checks in set_xen_raw_guest_handle we catch most of the
> > problem. They both ensure that the handle is 8-byte and the pointer is
> > valid. However we don't check that the padding is at the beginning of
> > the structure.
> >
> > It's better than what we have today as we don't even check that the
> > handle is 8-byte.
> >
> > [...]
> >
> > > > > This looses out on the arm32 hypervisor sanity checking that the
> > > > > padding
> > > > > bytes are 0 (as required by the ABI) but TBH I haven't checked
> > > > > that the
> > > > > current version has that property either.
> > > >
> > > > It's done during the assignation by the compiler:
> > > >
> > > > (hnd).q = (uint64_t)(uintptr_t)(val);
> > >
> > > I meant on the reading side.
> >
> > It's the responsibility of the caller to zero the padding. There is
> > nothing to do on the reading side, the hypervisor will use "p" which
> > will be the size of the natural pointer.
>
> Sorry to be pedantic, but why is this safe given that previously you
> wrote:
>
> Finally, based on the defect report #283 [2], the behavior of writing
> from one member and reading from another is not clear.
The writer via one is the guest and reader via the other is the hypervisor,
so no matter what they are certainly different compilation units, even in
the face of whole program optimisations.
The concerning issue is that if the compiler can observe you writing to
both halves of the union then it can either omit the first write or dive
off into deep undefined behaviour territory.
> Looks like it might be better to remove the union completely?
If that were possible I think someone would have suggested a scheme which
achieves it within the other constraints.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework
the macro set_xen_guest_handle_raw"):
> Finally, based on the defect report #283 [2], the behavior of writing
> from one member and reading from another is not clear.
Because the hypervisor is compiled with -fno-strict-aliasing.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
On Wed, 4 Nov 2015, Julien Grall wrote:
> On 04/11/15 11:27, Ian Campbell wrote:
> > On Wed, 2015-11-04 at 11:17 +, Julien Grall wrote:
> >>>
> >>> we could:
> >>> #ifdef(__XEN__)
> >>> #define XEN_BUILD_BUG_ON(x) BUILD_BUG_ON(x)
> >>> #elif !defined(XEN_BUILD_BUG_ON)
> >>> #define XEN_BUILD_BUG_ON(x)
> >>> #endif
> >>> and using XEN_BUILD_BUG_ON in the macro
> >>>
> >>> So, __XEN__ builds get the check and users can opt in by providing
> >>> XEN_BUILD_BUG_ON if they want. If they don't then they don't get the
> >>> check.
> >>
> >> I wouldn't let the user the choice to disable build-time check.
> >
> > Up to you. Note that "the user" here would potentially include
> > xen.git/tools, and I would expect them to want to define it.
> >
> > Also...
> >
> >> There is
> >> no harm to open-code them as I did today and avoid possible issue in the
> >> code later.
> >
> > ... there is always a downside to open coding. If you don't want to expose
> > the ability to define a BUG_ON to the application then just drop that #elif
> > from the chain.
>
> Good point. I will give a look.
>
> >
> >>> Or maybe we could just omit this from the public API by one or both of
> >>> a)
> >>> adding an explicit 8 byte type to the union purely to force the size
> >>> and/or
> >>
> >> This is already done in the current version:
> >>
> >> typedef union { type *p; uint64_aligned_t q; } \
> >> __guest_handle_64_ ## name;
> >>
> >> However I don't see how this ensure that the caller of
> >> set_xen_raw_guest_handle will effectively hnd as a pointer to an 8-byte
> >> placeholder.
> >
> > Not sure I follow. If hnd isn't a suitable struct xen guest handle then
> > other things will fail. If a user is passing a non struct xen_guest_handle
> > to this which happens to contain the same fields then more fool them, and
> > if it happens to be 8 bytes anyway your check won't catch that.
>
> With the 2 checks in set_xen_raw_guest_handle we catch most of the
> problem. They both ensure that the handle is 8-byte and the pointer is
> valid. However we don't check that the padding is at the beginning of
> the structure.
>
> It's better than what we have today as we don't even check that the
> handle is 8-byte.
>
> [...]
>
> >>> This looses out on the arm32 hypervisor sanity checking that the padding
> >>> bytes are 0 (as required by the ABI) but TBH I haven't checked that the
> >>> current version has that property either.
> >>
> >> It's done during the assignation by the compiler:
> >>
> >> (hnd).q = (uint64_t)(uintptr_t)(val);
> >
> > I meant on the reading side.
>
> It's the responsibility of the caller to zero the padding. There is
> nothing to do on the reading side, the hypervisor will use "p" which
> will be the size of the natural pointer.
Sorry to be pedantic, but why is this safe given that previously you
wrote:
Finally, based on the defect report #283 [2], the behavior of writing
from one member and reading from another is not clear.
Looks like it might be better to remove the union completely?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/6] xen/x86: Avoid using local labels for UNLIKELY() regions
>>> On 04.11.15 at 16:07, wrote: > On 04/11/15 14:45, Jan Beulich wrote: > On 30.10.15 at 20:59, wrote: >>> Using local labels causes the stack trace to use the last non-local >>> label emitted by the compiler in the translation unit, which is almost >>> always unrelated. >>> >>> e.g. A (contrived debug) example switches from: >>> >>> (XEN) [ Xen-4.7-unstable x86_64 debug=y Not tainted ] >>> (XEN) CPU:0 >>> (XEN) RIP:e008:[] >>> asm_domain_crash_synchronous+0x44/0x4c >>> ... >>> (XEN) Xen call trace: >>> (XEN)[] asm_domain_crash_synchronous+0x44/0x4c >>> (XEN)[] handle_keypress+0xa4/0xd9 >>> >>> to: >>> >>> (XEN) [ Xen-4.7-unstable x86_64 debug=y Not tainted ] >>> (XEN) CPU:0 >>> (XEN) RIP:e008:[] unlikely.vmptrld.921+0/0x8 >>> ... >>> (XEN) Xen call trace: >>> (XEN)[] unlikely.vmptrld.921+0/0x8 >>> (XEN)[] handle_keypress+0xa4/0xd9 >>> >>> which is far more relevant when identifying %eip. >> I disagree; I specifically used local labels here to avoid cluttering the >> symbol table. > > Needless cluttering is indeed bad. However, the effect here is a > misleading stack trace. > > As the entire point of the symbol table is to generate usable > information in situations like this, I don't see this as an issue. > >> If anything I'd agree to adding a label to the start of >> subsection 1 (or .fixup), > > How is this suggestion any different to what I have presented? Each > unlikely section still gets a non-local label. Your proposal produces one label per code addition to the unlikely section. My proposal generates just one label, no matter how many contributions to the section get done in a compilation unit. >> but it's not clear how emitting such labels >> could be avoided when that section is empty (such labels would clash >> with whatever label is first in the next compilation unit). > > All UNLIKELY() sections have content, as they are manually created. Or > have I missed something? I guess you take each .subsection as representation of a separate section, while I take only their set per compilation unit as one (and this being a sub-section means even that is still to wide a term). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] (XEN) APIC error on CPU0: 40(00)
Hi, i just build the latest 4.3.0 kernel and ran it on qubes-os with xen 4.4.3. I get this error just before the reboot: [(XEN) APIC error on CPU0: 40(00) (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. I can also see some weird acpi-related messages on the log i attached, like: (XEN) ACPI: Invalid sleep control/status register data: 0:0x8:0x3 0:0x8:0x3 (XEN) ERST table was not found [3.608404] ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20150818/dswload-210) [3.608410] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20150818/psobject-227) [3.608439] ACPI Exception: AE_NOT_FOUND, (SSDT:xh_rvp08) while loading table (20150818/tbxfload-193) [3.619914] ACPI Error: 1 table load failures, 5 successful (20150818/tbxfload-214) [3.679113] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [3.688942] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20150818/hwxface-580) [3.688948] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20150818/hwxface-580) [3.756027] PM-Timer failed consistency check (0xff) - aborting. With older kernels (like 3.12 or 4.2.1) i always see those messages but i'm able to boot without the acpi error. My machine runs on skylake cpu with z170 chipset and the latest bios. Any ideas on how to fix this? Thanks, John. Loading Xen 4.4.3 ... Loading Linux 4.3-0.pvops.qubes.x86_64 ... Xen 4.4.3-7.fc20 (XEN) Xen version 4.4.3 (user@) (gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)) debug=n Mon Oct 19 16:28:51 UTC 2015 (XEN) Latest ChangeSet: (XEN) Bootloader: GRUB 2.00 (XEN) Command line: placeholder console=ttyS0 com1=115200,8n1 console=com1 dom0_mem=min:1024Mi loglvl=all apic_verbosity=debug e820-verbose=true xsave=0 iommu=verbose (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Initial Xen-e820 RAM map: (XEN) - 0009c800 (usable) (XEN) 0009c800 - 000a (reserved) (XEN) 000e - 0010 (reserved) (XEN) 0010 - 61984000 (usable) (XEN) 61984000 - 61985000 (ACPI NVS) (XEN) 61985000 - 619cf000 (reserved) (XEN) 619cf000 - 61a22000 (usable) (XEN) 61a22000 - 62127000 (reserved) (XEN) 62127000 - 66b96000 (usable) (XEN) 66b96000 - 677ab000 (reserved) (XEN) 677ab000 - 67f9a000 (ACPI NVS) (XEN) 67f9a000 - 67fff000 (ACPI data) (XEN) 67fff000 - 6800 (usable) (XEN) 0001 - 00089200 (usable) (XEN) 6800 - 6810 (reserved) (XEN) e000 - f000 (reserved) (XEN) fe00 - fe011000 (reserved) (XEN) fec0 - fec01000 (reserved) (XEN) fee0 - fee01000 (reserved) (XEN) ff00 - 0001 (reserved) (XEN) Checking MTRR ranges... (XEN) MTRR cap: 1d0a type: c06 (XEN) Xen-e820 RAM map: (XEN) - 0009c800 (usable) (XEN) 0009c800 - 000a (reserved) (XEN) 000e - 0010 (reserved) (XEN) 0010 - 61984000 (usable) (XEN) 61984000 - 61985000 (ACPI NVS) (XEN) 61985000 - 619cf000 (reserved) (XEN) 619cf000 - 61a22000 (usable) (XEN) 61a22000 - 62127000 (reserved) (XEN) 62127000 - 66b96000 (usable) (XEN) 66b96000 - 677ab000 (reserved) (XEN) 677ab000 - 67f9a000 (ACPI NVS) (XEN) 67f9a000 - 67fff000 (ACPI data) (XEN) 67fff000 - 6800 (usable) (XEN) 6800 - 6810 (reserved) (XEN) e000 - f000 (reserved) (XEN) fe00 - fe011000 (reserved) (XEN) fec0 - fec01000 (reserved) (XEN) fee0 - fee01000 (reserved) (XEN) ff00 - 0001 (reserved) (XEN) 0001 - 00089200 (usable) (XEN) ACPI: RSDP 000F05B0, 0024 (r2 ALASKA) (XEN) ACPI: XSDT 67A1F098, 00B4 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: FACP 67A41B30, 010C (r5 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: DSDT 67A1F1E8, 22943 (r2 ALASKA A M I 1072009 INTL 20120913) (XEN) ACPI: FACS 67F99F80, 0040 (XEN) ACPI: APIC 67A41C40, 00BC (r3 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: FPDT 67A41D00, 0044 (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: FIDT 67A41D48, 009C (r1 ALASKA A M I 1072009 AMI 10013) (XEN) ACPI: MCFG 67A41DE8, 003C (r1 ALASKAA M I 1072009 MSFT 97) (XEN) ACPI: HPET 67A41E28, 0038 (r1 ALASKA
[Xen-devel] Xen 4.5.2 released
All, I am pleased to announce the release of Xen 4.5.2. This is available immediately from its git repository http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.5 (tag RELEASE-4.5.2) or from the XenProject download page http://www.xenproject.org/downloads/xen-archives/xen-45-series/xen-452.html (where a list of changes can also be found). We recommend all users of the 4.5 stable series to update to this latest point release. Regards, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/6] xen/x86: Avoid using local labels for UNLIKELY() regions
On 04/11/15 14:45, Jan Beulich wrote: On 30.10.15 at 20:59, wrote: >> Using local labels causes the stack trace to use the last non-local >> label emitted by the compiler in the translation unit, which is almost >> always unrelated. >> >> e.g. A (contrived debug) example switches from: >> >> (XEN) [ Xen-4.7-unstable x86_64 debug=y Not tainted ] >> (XEN) CPU:0 >> (XEN) RIP:e008:[] >> asm_domain_crash_synchronous+0x44/0x4c >> ... >> (XEN) Xen call trace: >> (XEN)[] asm_domain_crash_synchronous+0x44/0x4c >> (XEN)[] handle_keypress+0xa4/0xd9 >> >> to: >> >> (XEN) [ Xen-4.7-unstable x86_64 debug=y Not tainted ] >> (XEN) CPU:0 >> (XEN) RIP:e008:[] unlikely.vmptrld.921+0/0x8 >> ... >> (XEN) Xen call trace: >> (XEN)[] unlikely.vmptrld.921+0/0x8 >> (XEN)[] handle_keypress+0xa4/0xd9 >> >> which is far more relevant when identifying %eip. > I disagree; I specifically used local labels here to avoid cluttering the > symbol table. Needless cluttering is indeed bad. However, the effect here is a misleading stack trace. As the entire point of the symbol table is to generate usable information in situations like this, I don't see this as an issue. > If anything I'd agree to adding a label to the start of > subsection 1 (or .fixup), How is this suggestion any different to what I have presented? Each unlikely section still gets a non-local label. > but it's not clear how emitting such labels > could be avoided when that section is empty (such labels would clash > with whatever label is first in the next compilation unit). All UNLIKELY() sections have content, as they are manually created. Or have I missed something? > Maybe we > could discard them in the symbols processing tool if their address > matches another symbol. > >> Additionally, correct the inclusion of the tag parameter in the C UNLIKELY >> blocks, to use the passed tag, rather than a literal ".tag". > This part I agree with of course, and would therefore like to as for this > to be split off. I will see about this, after we have agreed on the other bits. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] xen: sched: fix locking for insert_vcpu() in credit1 and RTDS
Hi Dario, 2015-11-04 9:12 GMT-05:00 Dario Faggioli : > On Mon, 2015-11-02 at 09:45 -0500, Meng Xu wrote: > > > > I guess maybe you forgot to change it in this commit but change > > > > it > > > > the > > > > following commit? > > > > > > > No, this is one of the few thing that changed between v2 and v3. > > > > > > Regards, > > > Dario > > > > Thanks for the explanation! Then the patch looks good to me, at least > > for RTDS scheduler. :-) > > > Thanks for looking at the patch. > > Just FTR (and for next time :-D), is the above something that can be > interpreted as a 'Reviewed-by: Meng Xu ' ? If no (e.g., because > you haven't looking thoroughly enough to feel confident to express it), > then fine, I was just asking. > Thank you very much for explaining this for me. :-) I feel confident about the changes for RTDS scheduler. I'm not so confident about the change in the schedule.c. To be specific, this patch removes insert_vcpu in schedule_cpu_switch () in schedule.c; I'm not so sure if it is ok to insert_vcpu when a domain is moved. (Next time, I will stand out and ask although it may be a stupid question. ;-) ) So as to this patch, I will say: As far as the RTDS scheduler is concerned: Reviewed-by: Meng Xu < men...@cis.upenn.edu > > > If yes, I encourage you to say it explicitly, to avoid errors and > misjudgements. If you 'only' looked at the patch with the RTDS > scheduler in mind, that is fine too. You can say something like "As far > as the RTDS scheduler is concerned: Reviewed-by: Meng Xu ". Other > reviewers and committers will take this into account and properly > weight it. > > Every akc/review is important, and, if you took the time to look at a > patch, why don't say it in the proper way? :-) > Sure! I will keep this in mind. > I'm about to send v4 of this series. Feel free (only if you want, of > course!), to chime in in that thread. > Sure. I will try to have a look. :-) Thanks, 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] [ovmf baseline-only test] 38247: all pass
This run is configured for baseline tests only. flight 38247 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38247/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf fad21b7c57336bbf0ae363d56e35cbccca67ff3b baseline version: ovmf 8aa6ebe83f91fcd5e1a67d316e444f4ac8b1319d Last test of basis38245 2015-11-03 08:58:06 Z1 days Testing same since38247 2015-11-04 12:50:28 Z0 days1 attempts People who touched revisions under test: Cinnamon Shia Jeff Fan Michael Kinney Ruiyu Ni Samer El-Haj-Mahmoud Sunny Wang 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 fad21b7c57336bbf0ae363d56e35cbccca67ff3b Author: Sunny Wang Date: Tue Nov 3 02:58:30 2015 + MdeModulePkg: Fix memory leak issues Fix memory leak issues Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Sunny Wang Reviewed-by: Ruiyu Ni git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18722 6f19259b-4bc3-4df7-8a09-765794883524 commit e7e346962b2ae6fcf05b840149cb0b1768173ae2 Author: Cinnamon Shia Date: Tue Nov 3 02:44:48 2015 + MdeModulePkg/RegularExpressionDxe: Add missing PrintLib AsciiVSPrint is used in RegularExpressionDxe/Oniguruma/OnigurumaUefiPort.c. But PrintLib is missing in RegularExpressionDxe.inf. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia Reviewed-by: Samer El-Haj-Mahmoud git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18721 6f19259b-4bc3-4df7-8a09-765794883524 commit 0af8e57c740304a5ee79d40d227b673fa9f223ef Author: Cinnamon Shia Date: Tue Nov 3 02:43:03 2015 + MdeModulePkg/RegularExpressionDxe: Correct copyright Correct copyrights in RegularExpressionDxe Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia Reviewed-by: Samer El-Haj-Mahmoud git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18720 6f19259b-4bc3-4df7-8a09-765794883524 commit c7e7613e09ff10257dfc301ac1cd3bff807e6c02 Author: Ruiyu Ni Date: Tue Nov 3 02:34:21 2015 + MdeModulePkg: Fix a PciBusDxe hot plug bug For a hot plug bridge with device attached, PciBusDxe driver reserves the resources which equal to the total amount of padding resource returned from HotPlug->GetResourcePadding() and the actual occupied resource by the attached device. The behavior is incorrect. Correct behavior is to reserve the bigger one between the padding resource and the actual occupied resource. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Reviewed-by: Feng Tian git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18719 6f19259b-4bc3-4df7-8a09-765794883524 commit f67bd32ddaae9d5c11481007bbd63e0a3e881f3a Author: Ruiyu Ni Date: Tue Nov 3 02:33:41 2015 + MdeModulePkg: Fix a PCI resource dumping bug in PciBusDxe driver The resource dumping logic contains a bug which cannot dump the resource for hot plug controller correctly. The patch fixes this bug. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Reviewed-by: Feng Tian git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18718 6f19259b-4bc3-4df7-8a09-765794883524 commit b3800cfd10abe8033e16147ad16b01cd16aae0d7 Author: Ruiyu Ni Date: Tue Nov 3 02:33:05 2015 + Revert "MdeModulePkg: Fix a PciBusDxe hot plug bug" Leif suggested to split the big patch to smaller ones. This reverts commit 73b7f115c653c807b9d0be97bf516871d8aff7ba. Contributed-under: TianoCore Contribution Agr
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
On Wed, 2015-11-04 at 14:42 +, Julien Grall wrote: > On 04/11/15 14:29, Ian Campbell wrote: > > > > > > This looses out on the arm32 hypervisor sanity checking that > > > > > > the > > > > > > padding > > > > > > bytes are 0 (as required by the ABI) but TBH I haven't checked > > > > > > that > > > > > > the > > > > > > current version has that property either. > > > > > > > > > > It's done during the assignation by the compiler: > > > > > > > > > > (hnd).q = (uint64_t)(uintptr_t)(val); > > > > > > > > I meant on the reading side. > > > > > > It's the responsibility of the caller to zero the padding. There is > > > nothing to do on the reading side, the hypervisor will use "p" which > > > will be the size of the natural pointer. > > > > For a 32-bit Xen the check would be that a guest was not inadvertently > > violating this rule, such a guest would crash if it was run on a 64-bit > > hypervisor (which would see the non-zero padding as part of the > > pointer), > > by rejecting such cases on 32-bit Xen we avoid such guests becoming > > established and therefore presenting a case for us to relax this rule > > in > > one way or another. > > It would add overhead each time we want to copy to/from the guest memory. I was simply commenting that the approach taken here might be removing such a check _if_ it exists today, and as I said up front I'm not sure we have such a check right now or not. I'm not suggesting you add one as a new check, just that _if_ it already exists then it being removed needs to be considered. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/6] xen/x86: Avoid using local labels for UNLIKELY() regions
>>> On 30.10.15 at 20:59, wrote: > Using local labels causes the stack trace to use the last non-local > label emitted by the compiler in the translation unit, which is almost > always unrelated. > > e.g. A (contrived debug) example switches from: > > (XEN) [ Xen-4.7-unstable x86_64 debug=y Not tainted ] > (XEN) CPU:0 > (XEN) RIP:e008:[] > asm_domain_crash_synchronous+0x44/0x4c > ... > (XEN) Xen call trace: > (XEN)[] asm_domain_crash_synchronous+0x44/0x4c > (XEN)[] handle_keypress+0xa4/0xd9 > > to: > > (XEN) [ Xen-4.7-unstable x86_64 debug=y Not tainted ] > (XEN) CPU:0 > (XEN) RIP:e008:[] unlikely.vmptrld.921+0/0x8 > ... > (XEN) Xen call trace: > (XEN)[] unlikely.vmptrld.921+0/0x8 > (XEN)[] handle_keypress+0xa4/0xd9 > > which is far more relevant when identifying %eip. I disagree; I specifically used local labels here to avoid cluttering the symbol table. If anything I'd agree to adding a label to the start of subsection 1 (or .fixup), but it's not clear how emitting such labels could be avoided when that section is empty (such labels would clash with whatever label is first in the next compilation unit). Maybe we could discard them in the symbols processing tool if their address matches another symbol. > Additionally, correct the inclusion of the tag parameter in the C UNLIKELY > blocks, to use the passed tag, rather than a literal ".tag". This part I agree with of course, and would therefore like to as for this to be split off. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
On 04/11/15 14:29, Ian Campbell wrote: > This looses out on the arm32 hypervisor sanity checking that the > padding > bytes are 0 (as required by the ABI) but TBH I haven't checked that > the > current version has that property either. It's done during the assignation by the compiler: (hnd).q = (uint64_t)(uintptr_t)(val); >>> >>> I meant on the reading side. >> >> It's the responsibility of the caller to zero the padding. There is >> nothing to do on the reading side, the hypervisor will use "p" which >> will be the size of the natural pointer. > > For a 32-bit Xen the check would be that a guest was not inadvertently > violating this rule, such a guest would crash if it was run on a 64-bit > hypervisor (which would see the non-zero padding as part of the pointer), > by rejecting such cases on 32-bit Xen we avoid such guests becoming > established and therefore presenting a case for us to relax this rule in > one way or another. It would add overhead each time we want to copy to/from the guest memory. TBH, I don't think it's our business to check if the guest properly filling out the structure. It could happen only when the guest decides to implement it's own set_guest_handle_macro. As long as we don't crash the hypervisor it's fine. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
On Wed, 2015-11-04 at 11:40 +, Julien Grall wrote: > > Not sure I follow. If hnd isn't a suitable struct xen guest handle then > > other things will fail. If a user is passing a non struct > > xen_guest_handle > > to this which happens to contain the same fields then more fool them, > > and > > if it happens to be 8 bytes anyway your check won't catch that. > > With the 2 checks in set_xen_raw_guest_handle we catch most of the > problem. They both ensure that the handle is 8-byte and the pointer is > valid. However we don't check that the padding is at the beginning of > the structure. > > It's better than what we have today as we don't even check that the > handle is 8-byte. I'm not sure I'm all that worried about callers constructing their own guest handle structs and getting it wrong. > [...] > > > > > This looses out on the arm32 hypervisor sanity checking that the > > > > padding > > > > bytes are 0 (as required by the ABI) but TBH I haven't checked that > > > > the > > > > current version has that property either. > > > > > > It's done during the assignation by the compiler: > > > > > > (hnd).q = (uint64_t)(uintptr_t)(val); > > > > I meant on the reading side. > > It's the responsibility of the caller to zero the padding. There is > nothing to do on the reading side, the hypervisor will use "p" which > will be the size of the natural pointer. For a 32-bit Xen the check would be that a guest was not inadvertently violating this rule, such a guest would crash if it was run on a 64-bit hypervisor (which would see the non-zero padding as part of the pointer), by rejecting such cases on 32-bit Xen we avoid such guests becoming established and therefore presenting a case for us to relax this rule in one way or another. This is the same reason as check_multicall_32bit_clean() exists. multicall is special only in that it was pretty easy to know where to add that check. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] symbols.c: Avoid warn_unused_result build failure on fgets().
On Wed, 2015-11-04 at 13:39 +0200, Riku Voipio wrote: Not to do with this patch (and this suggestion wouldn't have helped in this case) but IIRC Linaro tests the xen.git#staging branch. We recently introduced a new "smoke test" phase which is a quick[0] test which runs on staging before the regular big test runs to check for obvious errors, build problems, simple guest booting etc. The sequence of tests on xen's development branch is now: * A committer pushes to xen.git#staging * osstest runs smoke tests on staging and propagates passes to xen.git#smoked * osstest runs full suite of tests tests on smoked and propagates passes to xen.git#master I mention this because perhaps Linaro would want to switch to running their tests on #smoked instead of #staging, and avoid the cases where things are completely knackered? In this case the compiler which osstest uses apparently doesn't warn about fgets() not being checked, so it wouldn't actually have helped... Ian. [0] ~2 hours turnaround, compared with a day or more for regular test flights. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] xen: sched: fix locking for insert_vcpu() in credit1 and RTDS
On Mon, 2015-11-02 at 09:45 -0500, Meng Xu wrote: > > > I guess maybe you forgot to change it in this commit but change > > > it > > > the > > > following commit? > > > > > No, this is one of the few thing that changed between v2 and v3. > > > > Regards, > > Dario > > Thanks for the explanation! Then the patch looks good to me, at least > for RTDS scheduler. :-) > Thanks for looking at the patch. Just FTR (and for next time :-D), is the above something that can be interpreted as a 'Reviewed-by: Meng Xu ' ? If no (e.g., because you haven't looking thoroughly enough to feel confident to express it), then fine, I was just asking. If yes, I encourage you to say it explicitly, to avoid errors and misjudgements. If you 'only' looked at the patch with the RTDS scheduler in mind, that is fine too. You can say something like "As far as the RTDS scheduler is concerned: Reviewed-by: Meng Xu ". Other reviewers and committers will take this into account and properly weight it. Every akc/review is important, and, if you took the time to look at a patch, why don't say it in the proper way? :-) I'm about to send v4 of this series. Feel free (only if you want, of course!), to chime in in that thread. Thanks again and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] symbols.c: Avoid warn_unused_result build failure on fgets().
>>> On 04.11.15 at 12:39, wrote: > In commit: > > d37d63d symbols: prefix static symbols with their source file names > > An unchecked fgets was added. This causes a compile error: > > symbols.c: In function 'read_symbol': > symbols.c:181:3: error: ignoring return value of 'fgets', declared with > attribute warn_unused_result [-Werror=unused-result] >fgets(str, 500, in); /* discard rest of line */ >^ > > Paper over the warning like in the other similar fgets-on-error-path > earlier in the same file. But the two cases are dissimilar - the original one skips a line the format of which is not recognized, while here you may be converting success into an error. (I did notice the comment on the earlier fgets(), but since so far I didn't get any compiler warning on any system I built this on, I assumed we'd be fine without the check, since if we need the check, then it will end up even more clumsy than the other one.) > --- a/xen/tools/symbols.c > +++ b/xen/tools/symbols.c > @@ -178,8 +178,8 @@ static int read_symbol(FILE *in, struct sym_entry *s) > > skip_tail: > if (input_format == fmt_sysv) > - fgets(str, 500, in); /* discard rest of line */ > - > + if (fgets(str, 500, in) == NULL) /* discard rest of line */ > + return -1; /* must check fgets result */ As to formal things - two such consecutive if()-s should be combined. Since we really want to ignore the return value here, perhaps just cast the function result to void? (I admit that I don't recall whether this would take care of that compiler warning.) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 63594: tolerable all pass - PUSHED
flight 63594 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63594/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
version targeted for testing:
xen 6919a7dde48bf1a9314c328bfb93a8a2f741bb80
baseline version:
xen 700772bc13a3d4e7a61cea166893c0f53b251f08
Last test of basis63584 2015-11-04 10:01:27 Z0 days
Testing same since63594 2015-11-04 12:00:59 Z0 days1 attempts
People who touched revisions under test:
Ian Campbell
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=6919a7dde48bf1a9314c328bfb93a8a2f741bb80
+ . ./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
6919a7dde48bf1a9314c328bfb93a8a2f741bb80
+ branch=xen-unstable-smoke
+ revision=6919a7dde48bf1a9314c328bfb93a8a2f741bb80
+ . ./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-unstable
+ '[' x6919a7dde48bf1a9314c328bfb93a8a2f741bb80 = 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:
[Xen-devel] [linux-3.10 test] 63529: regressions - FAIL
flight 63529 linux-3.10 real [real] http://logs.test-lab.xenproject.org/osstest/logs/63529/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 5 kernel-build fail REGR. vs. 62642 Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-xsm 18 guest-start/debian.repeat fail in 63391 pass in 63529 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail pass in 63391 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 63391 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 63391 blocked in 62642 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62642 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 62642 Tests which did not succeed, but are not blocking: 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 12 migrate-support-checkfail 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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass version targeted for testing: linuxd17332ebfb5f2010ae5d3332a52df361f28ae4a8 baseline version: linuxf5552cd830e58c46dffae3617b3ce0c839771981 Last test of basis62642 2015-10-03 17:59:45 Z 31 days Failing since 63224 2015-10-22 22:20:05 Z 12 days 10 attempts Testing same since63332 2015-10-27 12:23:40 Z8 days6 attempts People who touched revisions under test: "Eric W. Biederman" Aaron Conole Adam Radford Al Viro Alexander Couzens Alexey Klimov Andi Kleen Andreas Schwab Andrew Morton Ard Biesheuvel Arnaldo Carvalho de Melo Ben Hutchings Charles Keepax Christoph Biedl Christoph Hellwig cov...@ccs.covici.com Daniel Vetter Daniel Vetter Dave Kleikamp David S. Miller David Vrabel David Woodhouse David Woodhouse Ding Tianhong dingtianhong Dirk Mueller Dirk Müller Doug Ledford Eric Dumazet Eric W. Biederman Geert Uytterhoeven Greg Kroah-Hartman Guenter Roeck Guillaume Nault H. Peter Anvin Herbert Xu Ian Abbott Ilya Dryomov Ingo Molnar James Bottomley James Chapman James Hogan Jan Kara Jann Horn Jarkko Nikula Jeff Mahoney Jiri Slaby Joe Perches Joe Stringer Joe Thornber Johan Hovold John Covici Julian Anastasov Kees Cook Linus Torvalds Liu.Zhao Mark Brown Mark Salyzyn Mathias Nyman Mel Gorman Michael Ellerman Michal Hocko Michel Stam Mike Marciniszyn Mike Snitzer Mikulas Patocka Namhyung Kim NeilBrown Nicolas Pitre Nikolay Aleksandrov Oleksii Berezhniak Pablo Neira Ayuso Paolo Bonzini Paul Bolle Paul Mackerras Paul Mackerras Pravin B Shelar Ralf Baechle Reyad Attiyat Richard Weinberger Riku Voipio Riley Andrews Robert Jarzmik Roger Quadros Roland Dreier Russell King Samuel Thibault Shaohua Li Sheng Yong shengyong Simon Horman Stephen Smalley Steve French Steve French Takashi Iwai Tan, Jui Nee Tejun Heo Thomas Gleixner Tom Herbert Tóth Attila Vincent Palatin Vitaly Kuznetsov Will Deacon Wolfram Sang Wolfram Sang Yao-Wen Mao Yitian Bu Yitian Bu Zhang Zhen 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-pvopsfail build-
[Xen-devel] [ovmf test] 63530: all pass - PUSHED
flight 63530 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63530/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf fad21b7c57336bbf0ae363d56e35cbccca67ff3b
baseline version:
ovmf 8aa6ebe83f91fcd5e1a67d316e444f4ac8b1319d
Last test of basis63472 2015-11-02 02:10:32 Z2 days
Testing same since63530 2015-11-03 08:45:04 Z1 days1 attempts
People who touched revisions under test:
Cinnamon Shia
Jeff Fan
Michael Kinney
Ruiyu Ni
Samer El-Haj-Mahmoud
Sunny Wang
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=fad21b7c57336bbf0ae363d56e35cbccca67ff3b
+ . ./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 ovmf
fad21b7c57336bbf0ae363d56e35cbccca67ff3b
+ branch=ovmf
+ revision=fad21b7c57336bbf0ae363d56e35cbccca67ff3b
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' xfad21b7c57336bbf0ae363d56e35cbccca67ff3b = 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.com/
Re: [Xen-devel] [VOTE] Release cycle scheme
Wei Liu writes ("[VOTE] Release cycle scheme"):
> There are comments made by individuals that couldn't be clearly
> represent in tally. The most acceptable option to stable tree
> maintainers is #1.
>
> So I propose we use the following scheme:
+1
Following Ian Campbell's lead, I want to comment on the aspects of the
proposal:
> - 6 months release cycle from unstable branch.
+2
> - 4 months development.
> - 2 months freeze.
> - Eat into next cycle if doesn't release on time.
+2
> - Fixed cut-off date: the Fridays of the week in which the last day of
> March and September falls.
+1
You should perhaps adjust the wording here because the ends of a
"week" are slightly fuzzy. How about "the last Friday in March or
September" ?
(With my own definition of "week", which has weeks running Sunday to
Saturday, I think what you wrote means the same as "the Friday after
the last Sunday in March or September" - which is rather complex!)
> - No more freeze exception, but heads-up mails about freeze will be
> sent a few weeks before hand.
0
> - Stable branch maintained for 18 months full support plus 18 months
> security support. No mixed maintainership for stable trees.
+1
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/6] gitignore: Ignore *.orig, *.rej and *.swp files
Le 12 août 2015 11:04 AM, "Ian Campbell" a écrit : > > > (Having written the below I see too late that this is a grub patch not a > Xen one, a tag in the subject for such cross posted patches would be useful > please. Anyway, my opinion counts for very little in this context but I > leave it below since already I wrote it. I notice that xen.git#.gitignore > _does_ list *.rej, which I think is wrong...) > > On Mon, 2015-07-20 at 16:35 +0200, Daniel Kiper wrote: > > Signed-off-by: Daniel Kiper > > At least *.rej and perhaps *.orig are indicative of a failed patch > application, I think I want them to appear in "git status". > > By way of comparison Linux's .gitignore includes *.orig but not *.rej and > Qemu's includes neither. > > So nack to the addition of *.rej from me. I'm more or less ambivalent about > *.orig. > I have to agree. You should clean up *.rej *.orig after fixing conflicts > > --- > > .gitignore |3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/.gitignore b/.gitignore > > index 18ab8e8..6d25d39 100644 > > --- a/.gitignore > > +++ b/.gitignore > > @@ -147,6 +147,7 @@ mod-*.c > > missing > > netboot_test > > *.o > > +*.orig > > *.a > > ohci_test > > partmap_test > > @@ -160,9 +161,11 @@ po/stamp-po > > printf_test > > priority_queue_unit_test > > pseries_test > > +*.rej > > stamp-h > > stamp-h1 > > stamp-h.in > > +*.swp > > symlist.c > > symlist.h > > trigtables.c ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xl: avoid (another) uninitialised use of rc in vcpuset()
Rearange the case when we check the new number of vCPUs
against the number of host pCPUs not to use rc for internal
error reporting. In fact:
- rc was at risk of being used uninitialised;
- rc should only be used for holding libxl error codes.
Signed-off-by: Dario Faggioli
---
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Wei Liu
Cc: Harmandeep Kaur
Cc: Andrew Cooper
---
tools/libxl/xl_cmdimpl.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 9b6b42c..78048a1 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5457,21 +5457,21 @@ static int vcpuset(uint32_t domid, const char*
nr_vcpus, int check_host)
* by the host's amount of pCPUs.
*/
if (check_host) {
-unsigned int host_cpu = libxl_get_max_cpus(ctx);
+unsigned int online_vcpus, host_cpu = libxl_get_max_cpus(ctx);
libxl_dominfo dominfo;
if (libxl_domain_info(ctx, &dominfo, domid))
return 1;
-if (max_vcpus > dominfo.vcpu_online && max_vcpus > host_cpu) {
+online_vcpus = dominfo.vcpu_online;
+libxl_dominfo_dispose(&dominfo);
+
+if (max_vcpus > online_vcpus && max_vcpus > host_cpu) {
fprintf(stderr, "You are overcommmitting! You have %d physical" \
" CPUs and want %d vCPUs! Aborting, use --ignore-host to" \
" continue\n", host_cpu, max_vcpus);
-rc = 1;
-}
-libxl_dominfo_dispose(&dominfo);
-if (rc)
return 1;
+}
}
rc = libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus);
if (rc) {
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Linux 4.4 MW: Boot under Xen fails with CONFIG_DEBUG_WX enabled: RIP: ptdump_walk_pgd_level_core
Hi All, I just tried to boot with the current linus mergewindow tree under Xen. It fails with a kernel panic at boot with the new "CONFIG_DEBUG_WX" option enabled. Disabling it makes the kernel boot fine. The splat: [ 18.424241] Freeing unused kernel memory: 1104K (822fc000 - 8241) [ 18.430314] Write protecting the kernel read-only data: 18432k [ 18.441054] Freeing unused kernel memory: 1144K (880001ae2000 - 880001c0) [ 18.447966] Freeing unused kernel memory: 1560K (88000207a000 - 88000220) [ 18.453947] BUG: unable to handle kernel paging request at 88055c883000 [ 18.459943] IP: [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.465847] PGD 2212067 PUD 0 [ 18.471564] Oops: [#1] SMP [ 18.477248] Modules linked in: [ 18.482918] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.3.0-mw-20151104-linus-doflr+ #1 [ 18.488804] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [ 18.494778] task: 880059b9 ti: 880059b98000 task.ti: 880059b98000 [ 18.500852] RIP: e030:[] [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.507102] RSP: e02b:880059b9be48 EFLAGS: 00010296 [ 18.513351] RAX: 88055c883000 RBX: 81ae2000 RCX: 8800 [ 18.519733] RDX: 0067 RSI: 880059b9be98 RDI: 88001000 [ 18.526129] RBP: 880059b9bf00 R08: R09: [ 18.532522] R10: 88005fd0e790 R11: 0001 R12: 88008000 [ 18.538891] R13: cfff R14: 880059b9be98 R15: [ 18.545247] FS: () GS:88005f68() knlGS: [ 18.551708] CS: e033 DS: ES: CR0: 8005003b [ 18.558153] CR2: 88055c883000 CR3: 02211000 CR4: 0660 [ 18.564686] Stack: [ 18.571106] 000159b9be50 82211000 88055c884000 0800 [ 18.577704] 8000 88055c883000 0007 88005fd0e790 [ 18.584291] 880059b9bed8 81156ace 0001 [ 18.590916] Call Trace: [ 18.597458] [] ? free_reserved_area+0x11e/0x120 [ 18.604180] [] ptdump_walk_pgd_level_checkwx+0x12/0x20 [ 18.611014] [] mark_rodata_ro+0xe9/0xf0 [ 18.617819] [] ? rest_init+0x80/0x80 [ 18.624512] [] kernel_init+0x18/0xe0 [ 18.631095] [] ret_from_fork+0x3f/0x70 [ 18.637650] [] ? rest_init+0x80/0x80 [ 18.644178] Code: 70 ff ff ff 48 3b 85 58 ff ff ff 0f 84 c0 fe ff ff 48 8b 85 68 ff ff ff 48 c1 e0 10 48 c1 f8 10 48 89 45 b0 48 8b 85 70 ff ff ff <48> 8b 38 48 85 ff 0f 85 4e ff ff ff b9 02 00 00 00 31 d2 4c 89 [ 18.658246] RIP [] ptdump_walk_pgd_level_core+0x20e/0x440 [ 18.665211] RSP [ 18.672073] CR2: 88055c883000 [ 18.678852] ---[ end trace d84e34461c40637a ]--- [ 18.685641] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [ 18.685641] [ 18.699520] Kernel Offset: disable ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xl: initialise rc before using it in vcpuset
On Wed, 2015-11-04 at 11:47 +, Ian Campbell wrote:
> On Wed, 2015-11-04 at 12:38 +0100, Dario Faggioli wrote:
> > On Wed, 2015-11-04 at 11:32 +, Wei Liu wrote:
> >
> > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > > index 2756d2f..9b6b42c 100644
> > > --- a/tools/libxl/xl_cmdimpl.c
> > > +++ b/tools/libxl/xl_cmdimpl.c
> > > @@ -5473,7 +5473,8 @@ static int vcpuset(uint32_t domid, const
> > > char*
> > > nr_vcpus, int check_host)
> > > if (rc)
> > > return 1;
> > > }
> > > -if (libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus)) {
> > > +rc = libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus);
> > > +if (rc) {
> > > fprintf(stderr, "libxl_cpu_bitmap_alloc failed, rc:
> > > %d\n",
> > > rc);
> > > return 1;
> > > }
> > >
> > Don't we also need to initialise rc to 0? It seems to me that it
> > may be
> > used uninitialised also inside of if(check_host)...
>
> Looks like it, a separate issue though.
>
The compiler is not spotting it again, though (just as a side note).
> Don't initialise rc to 0, add a suitable else though.
>
Yeah, sure, I figured that out after having sent the mail. I'll send a
patch.
Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xl: initialise rc before using it in vcpuset
On Wed, 2015-11-04 at 12:38 +0100, Dario Faggioli wrote:
> On Wed, 2015-11-04 at 11:32 +, Wei Liu wrote:
>
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 2756d2f..9b6b42c 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -5473,7 +5473,8 @@ static int vcpuset(uint32_t domid, const char*
> > nr_vcpus, int check_host)
> > if (rc)
> > return 1;
> > }
> > -if (libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus)) {
> > +rc = libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus);
> > +if (rc) {
> > fprintf(stderr, "libxl_cpu_bitmap_alloc failed, rc: %d\n",
> > rc);
> > return 1;
> > }
> >
> Don't we also need to initialise rc to 0? It seems to me that it may be
> used uninitialised also inside of if(check_host)...
Looks like it, a separate issue though.
Don't initialise rc to 0, add a suitable else though.
>
> Regards,
> Dario
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw
On 04/11/15 11:27, Ian Campbell wrote:
> On Wed, 2015-11-04 at 11:17 +, Julien Grall wrote:
>>>
>>> we could:
>>> #ifdef(__XEN__)
>>> #define XEN_BUILD_BUG_ON(x) BUILD_BUG_ON(x)
>>> #elif !defined(XEN_BUILD_BUG_ON)
>>> #define XEN_BUILD_BUG_ON(x)
>>> #endif
>>> and using XEN_BUILD_BUG_ON in the macro
>>>
>>> So, __XEN__ builds get the check and users can opt in by providing
>>> XEN_BUILD_BUG_ON if they want. If they don't then they don't get the
>>> check.
>>
>> I wouldn't let the user the choice to disable build-time check.
>
> Up to you. Note that "the user" here would potentially include
> xen.git/tools, and I would expect them to want to define it.
>
> Also...
>
>> There is
>> no harm to open-code them as I did today and avoid possible issue in the
>> code later.
>
> ... there is always a downside to open coding. If you don't want to expose
> the ability to define a BUG_ON to the application then just drop that #elif
> from the chain.
Good point. I will give a look.
>
>>> Or maybe we could just omit this from the public API by one or both of
>>> a)
>>> adding an explicit 8 byte type to the union purely to force the size
>>> and/or
>>
>> This is already done in the current version:
>>
>> typedef union { type *p; uint64_aligned_t q; } \
>> __guest_handle_64_ ## name;
>>
>> However I don't see how this ensure that the caller of
>> set_xen_raw_guest_handle will effectively hnd as a pointer to an 8-byte
>> placeholder.
>
> Not sure I follow. If hnd isn't a suitable struct xen guest handle then
> other things will fail. If a user is passing a non struct xen_guest_handle
> to this which happens to contain the same fields then more fool them, and
> if it happens to be 8 bytes anyway your check won't catch that.
With the 2 checks in set_xen_raw_guest_handle we catch most of the
problem. They both ensure that the handle is 8-byte and the pointer is
valid. However we don't check that the padding is at the beginning of
the structure.
It's better than what we have today as we don't even check that the
handle is 8-byte.
[...]
>>> This looses out on the arm32 hypervisor sanity checking that the padding
>>> bytes are 0 (as required by the ABI) but TBH I haven't checked that the
>>> current version has that property either.
>>
>> It's done during the assignation by the compiler:
>>
>> (hnd).q = (uint64_t)(uintptr_t)(val);
>
> I meant on the reading side.
It's the responsibility of the caller to zero the padding. There is
nothing to do on the reading side, the hypervisor will use "p" which
will be the size of the natural pointer.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] symbols.c: Avoid warn_unused_result build failure on fgets().
In commit: d37d63d symbols: prefix static symbols with their source file names An unchecked fgets was added. This causes a compile error: symbols.c: In function 'read_symbol': symbols.c:181:3: error: ignoring return value of 'fgets', declared with attribute warn_unused_result [-Werror=unused-result] fgets(str, 500, in); /* discard rest of line */ ^ Paper over the warning like in the other similar fgets-on-error-path earlier in the same file. Cc: Jan Beulich Signed-off-by: Riku Voipio --- xen/tools/symbols.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/tools/symbols.c b/xen/tools/symbols.c index dbf6a1a..7e75be2 100644 --- a/xen/tools/symbols.c +++ b/xen/tools/symbols.c @@ -178,8 +178,8 @@ static int read_symbol(FILE *in, struct sym_entry *s) skip_tail: if (input_format == fmt_sysv) - fgets(str, 500, in); /* discard rest of line */ - + if (fgets(str, 500, in) == NULL) /* discard rest of line */ + return -1; /* must check fgets result */ return rc; } -- 2.6.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xl: initialise rc before using it in vcpuset
On Wed, 2015-11-04 at 11:32 +, Wei Liu wrote: > In 5b725e56 (xl: improve return and exit codes of vcpu related > functions), the return value of libxl_cpu_bitmap_alloc was not stored in > rc anymore. Yet the subsequent fprintf still used that. > > Reinstate the original implementation, that is, to store return value of > libxl_cpu_bitmap_alloc in rc before using rc. > > Signed-off-by: Wei Liu Acked + applied. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xl: initialise rc before using it in vcpuset
On Wed, 2015-11-04 at 11:32 +, Wei Liu wrote:
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 2756d2f..9b6b42c 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -5473,7 +5473,8 @@ static int vcpuset(uint32_t domid, const char*
> nr_vcpus, int check_host)
> if (rc)
> return 1;
> }
> -if (libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus)) {
> +rc = libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus);
> +if (rc) {
> fprintf(stderr, "libxl_cpu_bitmap_alloc failed, rc: %d\n",
> rc);
> return 1;
> }
>
Don't we also need to initialise rc to 0? It seems to me that it may be
used uninitialised also inside of if(check_host)...
Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 63584: tolerable all pass - PUSHED
flight 63584 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63584/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
version targeted for testing:
xen 700772bc13a3d4e7a61cea166893c0f53b251f08
baseline version:
xen 32b31c17da1ba0da970cd182a8865ac20fabd0fa
Last test of basis63544 2015-11-03 19:01:38 Z0 days
Testing same since63584 2015-11-04 10:01:27 Z0 days1 attempts
People who touched revisions under test:
Harmandeep Kaur
Ian Campbell
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=700772bc13a3d4e7a61cea166893c0f53b251f08
+ . ./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
700772bc13a3d4e7a61cea166893c0f53b251f08
+ branch=xen-unstable-smoke
+ revision=700772bc13a3d4e7a61cea166893c0f53b251f08
+ . ./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-unstable
+ '[' x700772bc13a3d4e7a61cea166893c0f53b251f08 = 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:
[Xen-devel] [PATCH v2] xl: initialise rc before using it in vcpuset
In 5b725e56 (xl: improve return and exit codes of vcpu related
functions), the return value of libxl_cpu_bitmap_alloc was not stored in
rc anymore. Yet the subsequent fprintf still used that.
Reinstate the original implementation, that is, to store return value of
libxl_cpu_bitmap_alloc in rc before using rc.
Signed-off-by: Wei Liu
---
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Dario Faggioli
Cc: Harmandeep Kaur
Cc: Andrew Cooper
v2: print rc.
---
tools/libxl/xl_cmdimpl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2756d2f..9b6b42c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5473,7 +5473,8 @@ static int vcpuset(uint32_t domid, const char* nr_vcpus,
int check_host)
if (rc)
return 1;
}
-if (libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus)) {
+rc = libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus);
+if (rc) {
fprintf(stderr, "libxl_cpu_bitmap_alloc failed, rc: %d\n", rc);
return 1;
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [VOTE] Release cycle scheme
On Mon, 2015-11-02 at 13:47 +, Wei Liu wrote: > > So I propose we use the following scheme: > > - 6 months release cycle from unstable branch. > - 4 months development. > - 2 months freeze. +1 > - Eat into next cycle if doesn't release on time. +2 > - Fixed cut-off date: the Fridays of the week in which the last day of > March and September falls. +2 > - No more freeze exception, but heads-up mails about freeze will be > sent a few weeks before hand. +2 > - Stable branch maintained for 18 months full support plus 18 months > security support. No mixed maintainership for stable trees. 0. > Please vote to ack or nack this proposal. Overall +1. I just wanted to highlight the three aspects which really matter IMHO (although I agree with George that the "Fixed..." and "No more..." are really up to the RM to decide). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
