[Xen-devel] [qemu-mainline test] 141466: regressions - FAIL
flight 141466 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/141466/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 140282 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 140282 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 140282 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 140282 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 140282 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 140282 test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuuf8c3db33a5e863291182f8862ddf81618a7c6194 baseline version: qemuuafd760539308a5524accf964107cdb1d54a059e3 Last test of basis 140282 2019-08-18 05:36:51 Z 33 days Failing since140361 2019-08-19 11:36:26 Z 31 days 38 attempts Testing same since 141434 2019-09-18 16:09:23 Z1 days2 attempts People who touched revisions under test: Alberto Garcia Aleksandar Markovic Alex Bennée Alexey Kardashevskiy Andrew Jeffery Andrey Shinkevich Anthony PERARD Aurelien Jarno BALATON Zoltan Bandan Das Bastian Koppelmann Carlo Marcelo Aren
[Xen-devel] [xen-unstable-smoke test] 141494: regressions - FAIL
flight 141494 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141494/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen ce44fd015e55d0ecc47c160fb5ce69070aa4991b baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Last test of basis 141253 2019-09-12 17:00:43 Z7 days Failing since141255 2019-09-12 21:01:22 Z7 days 49 attempts Testing same since 141489 2019-09-20 01:02:25 Z0 days2 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Chao Gao Christian Lindig Daniel De Graaf Ian Jackson Jan Beulich Juergen Gross Julien Grall Oleksandr Tyshchenko Paul Durrant Pawel Wieczorkiewicz Roger Pau Monné Stefano Stabellini Stefano Stabellini Volodymyr Babchuk Wei Liu Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1029 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v11] x86/emulate: Send vm_event from emulate
On 19.09.2019 16:59, Jan Beulich wrote:
> On 19.09.2019 15:03, Alexandru Stefan ISAILA wrote:
>> @@ -601,6 +602,7 @@ static void *hvmemul_map_linear_addr(
>>
>> case HVMTRANS_gfn_paged_out:
>> case HVMTRANS_gfn_shared:
>> +case HVMTRANS_bad_gfn_access:
>> err = ERR_PTR(~X86EMUL_RETRY);
>> goto out;
>
> This looks pretty suspicious now - why would (without knowing all
> the background) "bad access" translate into "retry". While you did
> post the suggested name before, it's nevertheless pretty clear now
> that it needs changing. Perhaps HVMTRANS_need_retry or some such?
It's fine by me, I will change the name to HVMTRANS_need_retry.
>
>> @@ -1852,6 +1864,8 @@ static int hvmemul_rep_movs(
>>
>> xfree(buf);
>>
>> +ASSERT(rc != HVMTRANS_bad_gfn_access);
>> +
>> if ( rc == HVMTRANS_gfn_paged_out )
>> return X86EMUL_RETRY;
>> if ( rc == HVMTRANS_gfn_shared )
>> @@ -1964,6 +1978,8 @@ static int hvmemul_rep_stos(
>> if ( buf != p_data )
>> xfree(buf);
>>
>> +ASSERT(rc != HVMTRANS_bad_gfn_access);
>> +
>> switch ( rc )
>> {
>> case HVMTRANS_gfn_paged_out:
>
> These are changes to places that were pointed out before do consume
> HVMTRANS_* return values. Did you go through and check nothing else
> needs adjustment? You don't say anything in this regard in the
> description. For example, if shadow's hvm_read() would get to see
> the new value, it would fall out of its switch() into a BUG().
>
Yes, you are right, the only thing that saves shadow from not raising a
BUG is the send_event flag. For safety reasons I will have a complete
check of all the places that can fail from adding the new return value.
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3236,6 +3236,19 @@ static enum hvm_translation_result __hvm_copy(
>> return HVMTRANS_bad_gfn_to_mfn;
>> }
>>
>> +/*
>> + * In case a vm event was sent return paged_out so the emulation
>> will
>> + * stop with no side effect
>> + */
>> +if ( (flags & HVMCOPY_linear) &&
>> + unlikely(v->arch.vm_event) &&
>> + v->arch.vm_event->send_event &&
>> + hvm_monitor_check_p2m(addr, gfn, pfec, npfec_kind_with_gla) )
>
> In such a sequence of checks with _some_ part using unlikely() I
> think it would be better to have the unlikely() one first (unless
> it's a relatively expensive check, which isn't the case here), to
> have as little as possible unnecessary computations / branches in
> the common (fast path) case.
I will change the order in the next version.
>
> Furthermore while you now restrict the check to linear address
> based accesses, other than the description says (or at least
> implies) you do not restrict it to read and exec accesses. It's
> not clear to me whether that's intentional, yet it affects which
> hvm_copy_*_linear() callers need auditing.
The pfec var is checked in hvm_monitor_check_p2m(). If you think it is
necessary I can add one more check here for (pfec & (PFEC_insn_fetch |
PFEC_write_access)).
>
> Finally, what about ->arch.vm_event->send_event remaining set
> after hvm_emulate_one_vm_event(), because hvm_monitor_check_p2m()
> (the only place where the flag would get cleared) was never hit
> in the process?
Thanks for pointing this out, indeed it's a problem here. A solution can
be to move send_event = false; after hvm_emulate_one_vm_event() is
finished. And state in the comment that the user is in charge of
enabling and disabling the flag.
Or just have it in both places.
> And what about an instruction accessing two (or
> more) distinct addresses? The flag would be clear after the first
> one was checked afaict.
There is no problem here because emulation will stop after the first bad
access so there is no need to continue.
Regards,
Alex
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v11] x86/emulate: Send vm_event from emulate
On 19.09.2019 17:09, Paul Durrant wrote:
>> -Original Message-
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index fdb1e17f59..4cc077bb3f 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3236,6 +3236,19 @@ static enum hvm_translation_result __hvm_copy(
>> return HVMTRANS_bad_gfn_to_mfn;
>> }
>>
>> +/*
>> + * In case a vm event was sent return paged_out so the emulation
>> will
>> + * stop with no side effect
>> + */
>> +if ( (flags & HVMCOPY_linear) &&
>> + unlikely(v->arch.vm_event) &&
>> + v->arch.vm_event->send_event &&
>> + hvm_monitor_check_p2m(addr, gfn, pfec, npfec_kind_with_gla) )
>> +{
>> +put_page(page);
>> +return HVMTRANS_bad_gfn_access;
>
> This doesn't match the comment above. Did you mean to return
> HVMTRANS_gfn_paged_out? I'm guessing not, in which case the comment needs to
> be fixed.
Yes, it seems I missed that but given that the return name will change I
will have the comment fixed in the next version. Thanks for pointing
this out.
Alex
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v11] x86/emulate: Send vm_event from emulate
On 20.09.2019 10:06, Alexandru Stefan ISAILA wrote: > On 19.09.2019 16:59, Jan Beulich wrote: >> Furthermore while you now restrict the check to linear address >> based accesses, other than the description says (or at least >> implies) you do not restrict it to read and exec accesses. It's >> not clear to me whether that's intentional, yet it affects which >> hvm_copy_*_linear() callers need auditing. > > The pfec var is checked in hvm_monitor_check_p2m(). If you think it is > necessary I can add one more check here for (pfec & (PFEC_insn_fetch | > PFEC_write_access)). hvm_monitor_check_p2m() gets called from two places, so a check there won't help (afaict). The question whether to put an additional check here depends on whether, as the description says, you really only want to handle read/exec accesses here, or whether you also want to cover write ones (in which case the description should be adjusted so that it's not misleading). >> Finally, what about ->arch.vm_event->send_event remaining set >> after hvm_emulate_one_vm_event(), because hvm_monitor_check_p2m() >> (the only place where the flag would get cleared) was never hit >> in the process? > Thanks for pointing this out, indeed it's a problem here. A solution can > be to move send_event = false; after hvm_emulate_one_vm_event() is > finished. And state in the comment that the user is in charge of > enabling and disabling the flag. > Or just have it in both places. For this aspect alone I think you want it in both places, but ... >> And what about an instruction accessing two (or >> more) distinct addresses? The flag would be clear after the first >> one was checked afaict. > > There is no problem here because emulation will stop after the first bad > access so there is no need to continue. ... for this moving it may indeed be necessary. I have to admit that I don't follow your reply here: The flag will also be clear after the first good access (afaict), and hence further accesses by the same insn won't make it into hvm_monitor_check_p2m() at all. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH RFC] pass-through: sync pir to irr after msix vector been updated
On 19.09.2019 23:38, Joe Jin wrote:
> On 9/19/19 3:24 AM, Jan Beulich wrote:
>> What's
>> still missing is the further updating of pirq_dpci->gmsi.dest_vcpu_id
>> (as explained before, still visible in context above).
>>
>
> 422
> 423 dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode);
> 424 pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id;
>
> dest_vcpu_id updated later by above code, do I missed something?
This piece of code
if ( iommu_intpost )
{
if ( delivery_mode == dest_LowestPrio )
vcpu = vector_hashing_dest(d, dest, dest_mode,
pirq_dpci->gmsi.gvec);
if ( vcpu )
pirq_dpci->gmsi.posted = true;
}
updates the vCPU to be delivered to. Right now, when the "posted"
flag is set, the dest_vcpu_id field is unused (as far as I was
able to tell), and hence didn't need setting. The way you intend
to change things, you want to use the field also in the "posted"
case, and hence you also should update it in the code path above.
But please double check all of this.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v11] x86/emulate: Send vm_event from emulate
On 20.09.2019 11:24, Jan Beulich wrote: > On 20.09.2019 10:06, Alexandru Stefan ISAILA wrote: >> On 19.09.2019 16:59, Jan Beulich wrote: >>> Furthermore while you now restrict the check to linear address >>> based accesses, other than the description says (or at least >>> implies) you do not restrict it to read and exec accesses. It's >>> not clear to me whether that's intentional, yet it affects which >>> hvm_copy_*_linear() callers need auditing. >> >> The pfec var is checked in hvm_monitor_check_p2m(). If you think it is >> necessary I can add one more check here for (pfec & (PFEC_insn_fetch | >> PFEC_write_access)). > > hvm_monitor_check_p2m() gets called from two places, so a check > there won't help (afaict). The question whether to put an > additional check here depends on whether, as the description > says, you really only want to handle read/exec accesses here, > or whether you also want to cover write ones (in which case the > description should be adjusted so that it's not misleading). Indeed covering write access here as well as in hvmemul_map_linear_addr() is needed. I will adjust the comment. > >>> Finally, what about ->arch.vm_event->send_event remaining set >>> after hvm_emulate_one_vm_event(), because hvm_monitor_check_p2m() >>> (the only place where the flag would get cleared) was never hit >>> in the process? >> Thanks for pointing this out, indeed it's a problem here. A solution can >> be to move send_event = false; after hvm_emulate_one_vm_event() is >> finished. And state in the comment that the user is in charge of >> enabling and disabling the flag. >> Or just have it in both places. > > For this aspect alone I think you want it in both places, but ... > >>> And what about an instruction accessing two (or >>> more) distinct addresses? The flag would be clear after the first >>> one was checked afaict. >> >> There is no problem here because emulation will stop after the first bad >> access so there is no need to continue. > > ... for this moving it may indeed be necessary. I have to admit > that I don't follow your reply here: The flag will also be clear > after the first good access (afaict), and hence further accesses > by the same insn won't make it into hvm_monitor_check_p2m() at all. > Ok I will move it from hvm_monitor_check_p2m() and adjust the comment accordingly. Thanks for the review, Alex ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] SVM: correct CPUID event processing
On 19.09.2019 13:37, Jan Beulich wrote: > hvm_monitor_cpuid() expects the input registers, not two of the outputs. > > However, once having made the necessary adjustment, the SVM and VMX > functions are so similar that they should be folded (thus avoiding > further similar asymmetries to get introduced). Use the best of both > worlds by e.g. using "curr" consistently. This then being the only > caller of hvm_check_cpuid_faulting(), fold in that function as well. > > Signed-off-by: Jan Beulich Reviewed-by: Alexandru Isaila > > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -3349,14 +3349,28 @@ unsigned long copy_from_user_hvm(void *t > return rc ? len : 0; /* fake a copy_from_user() return code */ > } > Useful fold. Maybe a small comment with the reason to have one function would help. Something like both SVM and VMX do the same thing, but it's up to you if it is necessary. > -bool hvm_check_cpuid_faulting(struct vcpu *v) > +int hvm_vmexit_cpuid(struct cpu_user_regs *regs, unsigned int inst_len) Alex ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] SVM: correct CPUID event processing
On 20.09.2019 10:39, Alexandru Stefan ISAILA wrote: > > > On 19.09.2019 13:37, Jan Beulich wrote: >> hvm_monitor_cpuid() expects the input registers, not two of the outputs. >> >> However, once having made the necessary adjustment, the SVM and VMX >> functions are so similar that they should be folded (thus avoiding >> further similar asymmetries to get introduced). Use the best of both >> worlds by e.g. using "curr" consistently. This then being the only >> caller of hvm_check_cpuid_faulting(), fold in that function as well. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Alexandru Isaila Thanks. >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -3349,14 +3349,28 @@ unsigned long copy_from_user_hvm(void *t >> return rc ? len : 0; /* fake a copy_from_user() return code */ >> } >> > > Useful fold. Maybe a small comment with the reason to have one function > would help. Something like both SVM and VMX do the same thing, but it's > up to you if it is necessary. > >> -bool hvm_check_cpuid_faulting(struct vcpu *v) >> +int hvm_vmexit_cpuid(struct cpu_user_regs *regs, unsigned int inst_len) The patch description explicitly says so. Since having common code for things not differing between vendors is the rule rather than an exception, commenting individual functions to this effect would seem rather odd to me. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm32: setup: Give a xenheap page to the boot allocator
On 20.09.2019 00:49, Stefano Stabellini wrote:
> On Tue, 17 Sep 2019, Julien Grall wrote:
>> @@ -665,6 +666,11 @@ static void __init setup_mm(void)
>>
>> setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages,
>> xenheap_pages);
>>
>> +/* We need a single mapped page for populating bootmem_region_list. */
>> +boot_mfn_start = mfn_add(xenheap_mfn_end, -1);
>> +boot_mfn_end = xenheap_mfn_end;
>> +init_boot_pages(mfn_to_maddr(boot_mfn_start),
>> mfn_to_maddr(boot_mfn_end));
>> +
>> /* Add non-xenheap memory */
>> for ( i = 0; i < bootinfo.mem.nr_banks; i++ )
>> {
>> @@ -710,7 +716,7 @@ static void __init setup_mm(void)
>>
>> /* Add xenheap memory that was not already added to the boot allocator.
>> */
>> init_xenheap_pages(mfn_to_maddr(xenheap_mfn_start),
>> - mfn_to_maddr(xenheap_mfn_end));
>> + mfn_to_maddr(boot_mfn_end));
>
> I can see what you are trying to do with this patch and it looks like
> the right fix at the moment. However, shouldn't this last change:
>
> mfn_to_maddr(boot_mfn_start)
Oh, indeed - when doing the review yesterday I thought I had
carefully compared with how things looked prior to the change
needing fixing up now, yet I didn't spot this (otherwise
obvious) difference to the original code.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] SVM: correct CPUID event processing
On 19/09/2019 11:37, Jan Beulich wrote: > hvm_monitor_cpuid() expects the input registers, not two of the outputs. Perhaps worth nothing that this has been broken since its introduction in c/s d05f1eb3741b85 ? > > However, once having made the necessary adjustment, the SVM and VMX > functions are so similar that they should be folded (thus avoiding > further similar asymmetries to get introduced). Use the best of both > worlds by e.g. using "curr" consistently. This then being the only > caller of hvm_check_cpuid_faulting(), fold in that function as well. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] SVM: correct CPUID event processing
On 20.09.2019 10:50, Andrew Cooper wrote: > On 19/09/2019 11:37, Jan Beulich wrote: >> hvm_monitor_cpuid() expects the input registers, not two of the outputs. > > Perhaps worth nothing that this has been broken since its introduction > in c/s d05f1eb3741b85 ? Ah, yes, I should have done this. I've added half a sentence. >> However, once having made the necessary adjustment, the SVM and VMX >> functions are so similar that they should be folded (thus avoiding >> further similar asymmetries to get introduced). Use the best of both >> worlds by e.g. using "curr" consistently. This then being the only >> caller of hvm_check_cpuid_faulting(), fold in that function as well. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Andrew Cooper Thanks. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 4/6] xen/x86: Allow stubdom access to irq created for msi.
On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -254,7 +254,13 @@ void __init clear_irq_vector(int irq)
> /*
> * Dynamic irq allocate and deallocation for MSI
> */
> -int create_irq(nodeid_t node)
> +
> +/*
> + * create_irq - allocate irq for MSI
> + * @d domain that will get permission over the allocated irq; this permission
> + * will automatically be revoked on destroy_irq
> + */
> +int create_irq(nodeid_t node, struct domain *d)
I think there's nothing wrong with the pointer getting constified,
but see also below.
> @@ -282,23 +288,30 @@ int create_irq(nodeid_t node)
> }
> ret = assign_irq_vector(irq, mask);
> }
> +ASSERT(desc->arch.creator_domid == DOMID_INVALID);
> if (ret < 0)
I think this insertion wants to gain blank lines on both sides.
> {
> desc->arch.used = IRQ_UNUSED;
> irq = ret;
> }
> -else if ( hardware_domain )
> +else if ( d )
> {
> -ret = irq_permit_access(hardware_domain, irq);
> +ASSERT(d == current->domain);
Why pass in the domain then in the first place? Could by just a
boolean, couldn't it? Suitably named it might even eliminate
the need for the explanatory comment (see also below).
> +ret = irq_permit_access(d, irq);
> if ( ret )
> printk(XENLOG_G_ERR
> - "Could not grant Dom0 access to IRQ%d (error %d)\n",
> - irq, ret);
> + "Could not grant Dom%u access to IRQ%d (error %d)\n",
> + d->domain_id, irq, ret);
Please use %pd here (and elsewhere).
> +else
> +desc->arch.creator_domid = d->domain_id;
> }
>
> return irq;
> }
>
> +/*
> + * destroy_irq - deallocate irq for MSI
> + */
> void destroy_irq(unsigned int irq)
I don't think this is a very helpful comment to add; in fact I think
the respective part on the other function would better be dropped as
well, seeing the further comment ahead of both functions. (Otherwise
I'd have to point out that this is a single line comment.)
> @@ -307,14 +320,25 @@ void destroy_irq(unsigned int irq)
>
> BUG_ON(!MSI_IRQ(irq));
>
> -if ( hardware_domain )
> +if ( desc->arch.creator_domid != DOMID_INVALID )
> {
> -int err = irq_deny_access(hardware_domain, irq);
> +struct domain *d = get_domain_by_id(desc->arch.creator_domid);
>
> -if ( err )
> -printk(XENLOG_G_ERR
> - "Could not revoke Dom0 access to IRQ%u (error %d)\n",
> - irq, err);
> +if ( d && irq_access_permitted(d, irq) )
> +{
> +int err;
> +
> +err = irq_deny_access(d, irq);
Please keep prior code structure, i.e. the function call being the
initializer of the variable.
> +if ( err )
> +printk(XENLOG_G_ERR
> + "Could not revoke Dom%u access to IRQ%u (error %d)\n",
> + d->domain_id, irq, err);
> +}
Why the irq_access_permitted() check around this? You go to some
lengths to explain this in the description, but if the domain has
no permission over the IRQ (because of domain ID re-use),
irq_deny_access() will simply do nothing, won't it? I.e. the way
this gets done and explained (saying that MSI IRQs can't be
shared between domains) wants to change a little.
> --- a/xen/include/asm-x86/irq.h
> +++ b/xen/include/asm-x86/irq.h
> @@ -45,6 +45,11 @@ struct arch_irq_desc {
> unsigned move_cleanup_count;
> u8 move_in_progress : 1;
> s8 used;
> +/*
> + * weak reference to domain having permission over this IRQ (which
> can
> + * be different from the domain actually havint the IRQ assigned)
> + */
> +domid_t creator_domid;
Comment style (should start with a capital letter).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm32: setup: Give a xenheap page to the boot allocator
Hi Stefano,
On 20/09/2019 09:48, Jan Beulich wrote:
On 20.09.2019 00:49, Stefano Stabellini wrote:
On Tue, 17 Sep 2019, Julien Grall wrote:
@@ -665,6 +666,11 @@ static void __init setup_mm(void)
setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
+/* We need a single mapped page for populating bootmem_region_list. */
+boot_mfn_start = mfn_add(xenheap_mfn_end, -1);
+boot_mfn_end = xenheap_mfn_end;
+init_boot_pages(mfn_to_maddr(boot_mfn_start), mfn_to_maddr(boot_mfn_end));
+
/* Add non-xenheap memory */
for ( i = 0; i < bootinfo.mem.nr_banks; i++ )
{
@@ -710,7 +716,7 @@ static void __init setup_mm(void)
/* Add xenheap memory that was not already added to the boot allocator. */
init_xenheap_pages(mfn_to_maddr(xenheap_mfn_start),
- mfn_to_maddr(xenheap_mfn_end));
+ mfn_to_maddr(boot_mfn_end));
I can see what you are trying to do with this patch and it looks like
the right fix at the moment. However, shouldn't this last change:
mfn_to_maddr(boot_mfn_start)
Doh, yes it should. I will update the patch and resend it.
Oh, indeed - when doing the review yesterday I thought I had
carefully compared with how things looked prior to the change
needing fixing up now, yet I didn't spot this (otherwise
obvious) difference to the original code.
Jan
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH for-4.13 v2] xen/arm32: setup: Give a xenheap page to the boot allocator
After commit 6e3e771203 "xen/arm: setup: Relocate the Device-Tree later on
in the boot", the boot allocator will not receive any xenheap page (i.e.
mapped page) on Arm32.
However, the boot allocator implicitely rely on having the first page
already mapped and therefore result to break boot on Arm32.
The easiest way for now is to give a xenheap page to the boot allocator.
We may want to rethink the interface in the future.
Fixes: 6e3e771203 ('xen/arm: setup: Relocate the Device-Tree later on in the
boot')
Signed-off-by: Julien Grall
Reviewed-by: Jan Beulich
---
Changes in v2:
- Add Jan's reviewed-by
- Use boot_mfn_start rather than boot_mfn_end when giving
xenheap pages.
---
xen/arch/arm/setup.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 581b262655..fca7e68cba 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -593,6 +593,7 @@ static void __init setup_mm(void)
unsigned long heap_pages, xenheap_pages, domheap_pages;
int i;
const uint32_t ctr = READ_CP32(CTR);
+mfn_t boot_mfn_start, boot_mfn_end;
if ( !bootinfo.mem.nr_banks )
panic("No memory bank\n");
@@ -665,6 +666,11 @@ static void __init setup_mm(void)
setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
+/* We need a single mapped page for populating bootmem_region_list. */
+boot_mfn_start = mfn_add(xenheap_mfn_end, -1);
+boot_mfn_end = xenheap_mfn_end;
+init_boot_pages(mfn_to_maddr(boot_mfn_start), mfn_to_maddr(boot_mfn_end));
+
/* Add non-xenheap memory */
for ( i = 0; i < bootinfo.mem.nr_banks; i++ )
{
@@ -710,7 +716,7 @@ static void __init setup_mm(void)
/* Add xenheap memory that was not already added to the boot allocator. */
init_xenheap_pages(mfn_to_maddr(xenheap_mfn_start),
- mfn_to_maddr(xenheap_mfn_end));
+ mfn_to_maddr(boot_mfn_start));
}
#else /* CONFIG_ARM_64 */
static void __init setup_mm(void)
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early
Hi,
On 20/09/2019 00:37, Stefano Stabellini wrote:
On Tue, 17 Sep 2019, Julien Grall wrote:
The current implementations of xen_{map, unmap}_table() expect
{map, unmap}_domain_page() to be usable. Those helpers are used to
map/unmap page tables while update Xen page-tables.
Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT update in
{set, clear}_fixmap()", setup_fixmap() will make use of the helpers
mentioned above. When booting Xen using GRUB, setup_fixmap() may be used
before map_domain_page() can be called. This will result to data abort:
(XEN) Data Abort Trap. Syndrome=0x5
(XEN) CPU0: Unexpected Trap: Data Abort
[...]
(XEN) Xen call trace:
(XEN)[<0025ab6c>] mm.c#xen_pt_update+0x2b4/0x59c (PC)
(XEN)[<0025ab20>] mm.c#xen_pt_update+0x268/0x59c (LR)
(XEN)[<0025ae70>] set_fixmap+0x1c/0x2c
(XEN)[<002a9c98>] copy_from_paddr+0x7c/0xdc
(XEN)[<002a4ae0>] has_xsm_magic+0x18/0x34
(XEN)[<002a5b5c>] bootfdt.c#early_scan_node+0x398/0x560
(XEN)[<002a5de0>] device_tree_for_each_node+0xbc/0x144
(XEN)[<002a5ed4>] boot_fdt_info+0x6c/0x260
(XEN)[<002ac0d0>] start_xen+0x108/0xc74
(XEN)[<0020044c>] arm64/head.o#paging+0x60/0x88
During early boot, the page tables are either statically allocated in
Xen binary or allocated via alloc_boot_pages().
For statically allocated page-tables, they will already be mapped as
part of Xen binary. So we can easily find the virtual address.
For dynamically allocated page-tables, we need to rely
map_domain_page() to be functionally working.
For arm32, the call will be usable much before page can be dynamically
allocated (see setup_pagetables()). For arm64, the call will be usable
after setup_xenheap_mappings().
In both cases, memory are given to the boot allocator afterwards. So we
can rely on map_domain_page() for mapping page tables allocated
dynamically.
The helpers xen_{map, unmap}_table() are now updated to take into
account the case where page-tables are part of Xen binary.
Fixes: 022387ee1a ('xen/arm: mm: Don't open-code Xen PT update in {set,
clear}_fixmap()')
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 20
1 file changed, 20 insertions(+)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index e1cdeaaf2f..da6303a8fd 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -950,11 +950,31 @@ static int create_xen_table(lpae_t *entry)
static lpae_t *xen_map_table(mfn_t mfn)
{
+/*
+ * We may require to map the page table before map_domain_page() is
+ * useable. The requirements here is it must be useable as soon as
+ * page-tables are allocated dynamically via alloc_boot_pages().
+ */
+if ( system_state == SYS_STATE_early_boot )
+{
+vaddr_t va = mfn_to_maddr(mfn) - phys_offset;
+
+if ( is_kernel(va) )
+return (lpae_t *)va;
Is it intended to continue if it is not a xen text page? Shouldn't we
BUG() or WARN?
Yes, I wrote the rationale in the commit message and a summary in a few lines
above. For convenience, I pasted the commit message again here:
"During early boot, the page tables are either statically allocated in
Xen binary or allocated via alloc_boot_pages().
For statically allocated page-tables, they will already be mapped as
part of Xen binary. So we can easily find the virtual address.
For dynamically allocated page-tables, we need to rely
map_domain_page() to be functionally working.
For arm32, the call will be usable much before page can be dynamically
allocated (see setup_pagetables()). For arm64, the call will be usable
after setup_xenheap_mappings().
In both cases, memory are given to the boot allocator afterwards. So we
can rely on map_domain_page() for mapping page tables allocated
dynamically."
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 00/35] libxl refactoring to use ev_qmp (with API changes) [and 1 more messages]
On Thu, Sep 19, 2019 at 08:17:43PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v2 00/35] libxl refactoring to use ev_qmp
> (with API changes)"):
> > Patches with missing ackes:
> ...
> > libxl: Use ev_qmp in libxl_set_vcpuonline
>
> From my point of view I seem to have sent a ack for this,
>
>Message-ID: <23937.6842.426857.800...@mariner.uk.xensource.com>
>In-Reply-To: <20190802153606.32061-33-anthony.per...@citrix.com>
>References: <20190802153606.32061-1-anthony.per...@citrix.com>
><20190802153606.32061-33-anthony.per...@citrix.com>
>From: Ian Jackson
>To: Anthony PERARD
>Cc: "xen-devel@lists.xenproject.org" ,
>Wei Liu
>Subject: Re: [PATCH 32/35] libxl: Use ev_qmp in libxl_set_vcpuonline
>Date: Tue, 17 Sep 2019 18:41:14 +0100
>
> ? I hope it's not mail going missing again...
I didn't carry the acks because I've squashed a patch into this one and
I've change the commit message (adding an extra paragraph to reflect the
squashed commit).
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V4 5/8] xen/common: Introduce xrealloc_flex_struct() helper macros
Hi Jan On 13.09.2019 17:35, Oleksandr Tyshchenko wrote: --- a/xen/include/xen/xmalloc.h +++ b/xen/include/xen/xmalloc.h @@ -35,6 +35,15 @@ #define xzalloc_array(_type, _num) \ ((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num)) +/* Allocate space for a structure with a flexible array of typed objects. */ +#define xmalloc_flex_struct(type, field, nr) \ + (type *)_xmalloc(offsetof(type, field[nr]), __alignof__(type)) + +/* Re-allocate space for a structure with a flexible array of typed objects. */ +#define xrealloc_flex_struct(ptr, field, nr) \ + (typeof(ptr))_xrealloc(ptr, offsetof(typeof(*(ptr)), field[nr]), \ + __alignof__(typeof(*(ptr With the missing parentheses around the entire constructs added Reviewed-by: Jan Beulich Thank you. Would you be happy if I add xzalloc_flex_struct here as well (may I retain your R-b)? Actually the xzalloc_flex_struct better fits in [1] ... [1] https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg7.html -- Regards, Oleksandr Tyshchenko ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxc/x86: avoid overflow in CPUID APIC ID adjustments
On 19/09/2019 12:48, Jan Beulich wrote: > Recent AMD processors may report up to 128 logical processors in CPUID > leaf 1. Doubling this value produces 0 (which OSes sincerely dislike), > as the respective field is only 8 bits wide. Suppress doubling the value > (and its leaf 0x8008 counterpart) in such a case. > > Additionally don't even do any adjustment when the host topology already > includes room for multiple threads per core. > > Furthermore don't double the Maximum Cores Per Package at all - by us > introducing a fake HTT effect, the core count doesn't need to change. > Instead adjust the Maximum Logical Processors Sharing Cache field, which > so far was zapped altogether. > > Also zap leaf 4 (and at the same time leaf 2) EDX output for AMD. > > Signed-off-by: Jan Beulich > --- > TBD: Using xc_physinfo() output here needs a better solution. The > threads_per_core value returned is the count of active siblings of > CPU 0, rather than a system wide applicable value (and constant > over the entire session). Using CPUID output (leaves 4 and > 801e) doesn't look viable either, due to this not really being > the host values on PVH. Judging from the host feature set's HTT > flag also wouldn't tell us whether there actually are multiple > threads per core. The key thing is that htt != "more than one thread per core". HTT is strictly a bit indicating that topology information is available in a new form in the CPUID leaves (or in AMDs case, the same information should be interpreted in a new way). Just because HTT is set (and it does get set in non-HT capable systems), doesn't mean there is space for more than thread per core in topology information. For PV guests, my adjustment in the CPUID series shows (what I believe to be) the only correct way of propagating the host HTT/CMP_LEGACY settings through. For HVM guests, it really shouldn't really have anything to do with the host setting. We should be choosing how many threads/core to give to the guest, then constructing the topology information from first principles. Ignore the PVH case. It is totally broken for several other reasons as well, and PVH Dom0 isn't a production-ready thing yet. This gets us back to the PV case where the host information is actually in view, and (for backport purposes) can be trusted. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 5/6] xen/x86: add PHYSDEVOP_interrupt_control
On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
> Allow device model running in stubdomain to enable/disable INTx/MSI(-X),
> bypassing pciback. While pciback is still used to access config space
> from within stubdomain, it refuse to write to
> PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE/PCI_COMMAND_INTX_DISABLE
> in non-permissive mode. Which is the right thing to do for PV domain
> (the main use case for pciback), as PV domain should use XEN_PCI_OP_*
> commands for that. Unfortunately those commands are not good for
> stubdomain use, as they configure MSI in dom0's kernel too, which should
> not happen for HVM domain.
Why the "for HVM domain" here? I.e. why would this be correct for
a PV domain? Besides my dislike for such a bypass (imo all of the
handling should go through pciback, or none of it) I continue to
wonder whether the problem can't be addressed by a pciback change.
And even if not, I'd still wonder whether the request shouldn't go
through pciback, to retain proper layering. Ultimately it may be
better to have even the map/unmap go through pciback (it's at
least an apparent violation of the original physdev-op model that
these two are XSM_DM_PRIV).
Irrespective of this a couple of comments on the patch itself:
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -1443,6 +1443,51 @@ int pci_restore_msi_state(struct pci_dev *pdev)
> return 0;
> }
>
> +int msi_control(struct pci_dev *pdev, bool msix, bool enable)
> +{
> +unsigned int cap = msix ? PCI_CAP_ID_MSIX : PCI_CAP_ID_MSI;
> +unsigned int other_cap = msix ? PCI_CAP_ID_MSI : PCI_CAP_ID_MSIX;
> +uint16_t cmd;
> +
> +if ( !use_msi )
> +return -EOPNOTSUPP;
> +
> +if ( !pci_find_cap_offset(pdev->seg,
> + pdev->bus,
> + PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn),
Please don't use PCI_SLOT() and PCI_FUNC() anymore, now that we
have pdev->dev and pdev->fn. And please put multiple arguments
on one line, as many as will fit.
> + cap) )
> +return -ENODEV;
> +
> +cmd = pci_conf_read16(pdev->sbdf, PCI_COMMAND);
> +
> +/* don't allow enabling MSI(-X) and INTx at the same time */
> +if ( enable && ! (cmd & PCI_COMMAND_INTX_DISABLE) )
Stray blank after ! .
> +return -EBUSY;
> +
> +/* don't allow enabling both MSI and MSI-X at the same time */
> +if ( enable && find_msi_entry(pdev, -1, other_cap) )
> +return -EBUSY;
Combine both if()-s, since they both check "enable"?
Also - comment style again (should start with capital letter);
more instances elsewhere.
> +int intx_control(struct pci_dev *pdev, bool enable)
> +{
> +/* don't allow enabling INTx if MSI(-X) is already enabled */
> +if ( enable && find_msi_entry(pdev, -1, PCI_CAP_ID_MSI) )
> +return -EBUSY;
> +if ( enable && find_msi_entry(pdev, -1, PCI_CAP_ID_MSIX) )
> +return -EBUSY;
Here even more so you want to combine both if()-s.
> +pci_intx(pdev, enable);
> +return 0;
> +}
Blank line ahead of main return statement please, and I guess
another blank line ahead of the pci_intx() invocation wouldn't
hurt either.
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -662,6 +662,59 @@ ret_t do_physdev_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> break;
> }
>
> +case PHYSDEVOP_interrupt_control: {
> +struct physdev_interrupt_control op;
> +struct pci_dev *pdev;
> +int intr_type;
> +bool enable;
> +
> +ret = -EFAULT;
> +if ( copy_from_guest(&op, arg, 1) )
> +break;
> +
> +ret = -EINVAL;
> +if ( op.flags & ~(PHYSDEVOP_INTERRUPT_CONTROL_TYPE_MASK |
> + PHYSDEVOP_INTERRUPT_CONTROL_ENABLE) )
> +break;
> +
> +intr_type = op.flags & PHYSDEVOP_INTERRUPT_CONTROL_TYPE_MASK;
> +enable = op.flags & PHYSDEVOP_INTERRUPT_CONTROL_ENABLE;
> +
> +pcidevs_lock();
> +pdev = pci_get_pdev(op.seg, op.bus, op.devfn);
> +ret = -ENODEV;
> +/* explicitly exclude hidden devices */
> +if ( !pdev || pdev->domain == dom_xen )
The right side should be avoided by reducing the scope of the device
lookup right away, through use of pci_get_pdev_by_domain(). This
will also ensure we don't exclusively rely on the XSM check below to
prevent abuse of this operation. (FAOD, while
pci_get_pdev_by_domain() doesn't assert that the pcidevs lock is
held, you should still acquire it here. That missing ASSERT() should
get added as soon as other violators of the locking requirement have
been taken care of.)
> +goto pci_unlock;
> +
> +ret = xsm_interrupt_control(XSM_DM_PRIV,
> +pdev->domain,
> +pdev->sbdf.sbdf,
> +intr_type,
> +en
Re: [Xen-devel] [PATCH] libxc/x86: avoid overflow in CPUID APIC ID adjustments
On 20.09.2019 12:05, Andrew Cooper wrote: > On 19/09/2019 12:48, Jan Beulich wrote: >> Recent AMD processors may report up to 128 logical processors in CPUID >> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike), >> as the respective field is only 8 bits wide. Suppress doubling the value >> (and its leaf 0x8008 counterpart) in such a case. >> >> Additionally don't even do any adjustment when the host topology already >> includes room for multiple threads per core. >> >> Furthermore don't double the Maximum Cores Per Package at all - by us >> introducing a fake HTT effect, the core count doesn't need to change. >> Instead adjust the Maximum Logical Processors Sharing Cache field, which >> so far was zapped altogether. >> >> Also zap leaf 4 (and at the same time leaf 2) EDX output for AMD. >> >> Signed-off-by: Jan Beulich >> --- >> TBD: Using xc_physinfo() output here needs a better solution. The >> threads_per_core value returned is the count of active siblings of >> CPU 0, rather than a system wide applicable value (and constant >> over the entire session). Using CPUID output (leaves 4 and >> 801e) doesn't look viable either, due to this not really being >> the host values on PVH. Judging from the host feature set's HTT >> flag also wouldn't tell us whether there actually are multiple >> threads per core. > > The key thing is that htt != "more than one thread per core". HTT is > strictly a bit indicating that topology information is available in a > new form in the CPUID leaves (or in AMDs case, the same information > should be interpreted in a new way). Just because HTT is set (and it > does get set in non-HT capable systems), doesn't mean there is space for > more than thread per core in topology information. > > For PV guests, my adjustment in the CPUID series shows (what I believe > to be) the only correct way of propagating the host HTT/CMP_LEGACY > settings through. > > For HVM guests, it really shouldn't really have anything to do with the > host setting. We should be choosing how many threads/core to give to > the guest, then constructing the topology information from first principles. > > Ignore the PVH case. It is totally broken for several other reasons as > well, and PVH Dom0 isn't a production-ready thing yet. > > This gets us back to the PV case where the host information is actually > in view, and (for backport purposes) can be trusted. Okay, this means I'll revive and finish the half cpuid() based attempt I had made initially. A fundamental question remains open though from your reply: Do you agree with the idea of avoiding the multiplication by 2 if the host topology already provides at least one bit of thread ID within the APIC ID? Related to which then the question whether you also agree with my approach of ditching the adjustment to Maximum Cores Per Package? (I'm asking because I'd like to avoid several more round trips of the patch itself.) Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V4 5/8] xen/common: Introduce xrealloc_flex_struct() helper macros
On 20.09.2019 11:51, Oleksandr wrote: >>> On 13.09.2019 17:35, Oleksandr Tyshchenko wrote: --- a/xen/include/xen/xmalloc.h +++ b/xen/include/xen/xmalloc.h @@ -35,6 +35,15 @@ #define xzalloc_array(_type, _num) \ ((_type *)_xzalloc_array(sizeof(_type), __alignof__(_type), _num)) +/* Allocate space for a structure with a flexible array of typed objects. */ +#define xmalloc_flex_struct(type, field, nr) \ + (type *)_xmalloc(offsetof(type, field[nr]), __alignof__(type)) + +/* Re-allocate space for a structure with a flexible array of typed objects. */ +#define xrealloc_flex_struct(ptr, field, nr) \ + (typeof(ptr))_xrealloc(ptr, offsetof(typeof(*(ptr)), field[nr]), \ + __alignof__(typeof(*(ptr >>> With the missing parentheses around the entire constructs added >>> Reviewed-by: Jan Beulich >> >> Thank you. > > > Would you be happy if I add xzalloc_flex_struct here as well (may I > retain your R-b)? Yes to both. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 03/11] ioreq: switch selection and forwarding to use ioservid_t
On 10.09.2019 14:31, Paul Durrant wrote: >> -Original Message- >> From: Roger Pau Monne >> Sent: 03 September 2019 17:14 >> To: xen-devel@lists.xenproject.org >> Cc: Roger Pau Monne ; Jan Beulich ; >> Andrew Cooper >> ; Wei Liu ; George Dunlap >> ; Ian >> Jackson ; Julien Grall ; >> Konrad Rzeszutek Wilk >> ; Stefano Stabellini ; Tim >> (Xen.org) ; >> Paul Durrant >> Subject: [PATCH v2 03/11] ioreq: switch selection and forwarding to use >> ioservid_t >> >> hvm_select_ioreq_server and hvm_send_ioreq where both using >> hvm_ioreq_server directly, switch to use ioservid_t in order to select >> and forward ioreqs. >> >> This is a preparatory change, since future patches will use the ioreq >> server id in order to differentiate between internal and external >> ioreq servers. >> >> Signed-off-by: Roger Pau Monné > > Reviewed-by: Paul Durrant > > ... with one suggestion. > > [snip] >> diff --git a/xen/include/public/hvm/dm_op.h b/xen/include/public/hvm/dm_op.h >> index d3b554d019..8725cc20d3 100644 >> --- a/xen/include/public/hvm/dm_op.h >> +++ b/xen/include/public/hvm/dm_op.h >> @@ -54,6 +54,7 @@ >> */ >> >> typedef uint16_t ioservid_t; >> +#define XEN_INVALID_IOSERVID 0x >> > > Perhaps use (ioservid_t)~0 rather than hardcoding? And then (suitably parenthesized) applicable parts Acked-by: Jan Beulich Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 04/11] ioreq: add fields to allow internal ioreq servers
On 03.09.2019 18:14, Roger Pau Monne wrote:
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -52,21 +52,29 @@ struct hvm_ioreq_vcpu {
> #define MAX_NR_IO_RANGES 256
>
> struct hvm_ioreq_server {
> -struct domain *target, *emulator;
> -
> +struct domain *target;
> /* Lock to serialize toolstack modifications */
> spinlock_t lock;
> -
> -struct hvm_ioreq_page ioreq;
> -struct list_head ioreq_vcpu_list;
> -struct hvm_ioreq_page bufioreq;
> -
> -/* Lock to serialize access to buffered ioreq ring */
> -spinlock_t bufioreq_lock;
> -evtchn_port_t bufioreq_evtchn;
> struct rangeset*range[NR_IO_RANGE_TYPES];
> bool enabled;
> -uint8_tbufioreq_handling;
> +
> +union {
> +struct {
> +struct domain *emulator;
> +struct hvm_ioreq_page ioreq;
> +struct list_head ioreq_vcpu_list;
> +struct hvm_ioreq_page bufioreq;
> +
> +/* Lock to serialize access to buffered ioreq ring */
> +spinlock_t bufioreq_lock;
> +evtchn_port_t bufioreq_evtchn;
> +uint8_tbufioreq_handling;
> +};
> +struct {
> +void *data;
> +int (*handler)(struct vcpu *v, ioreq_t *, void *);
If you omit the latter two parameter names, the first one should
be omitted, too. And if there was to be any inconsistency in this
regard, then the one parameter where the type doesn't immediately
clarify the purpose would be the one to have a name.
As to the struct vcpu * parameter - is there an expectation that
the handler would be called with this being other than "current"?
If not, the parameter would want to either be dropped, or be
named "curr".
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 141471: regressions - FAIL
flight 141471 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141471/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 139910 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 139910 test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 139910 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linuxb10ab5e2c476b69689bc0c46d3094
Re: [Xen-devel] [PATCH v2 05/11] ioreq: add internal ioreq initialization support
On 03.09.2019 18:14, Roger Pau Monne wrote: > @@ -821,6 +851,9 @@ int hvm_create_ioreq_server(struct domain *d, int > bufioreq_handling, > if ( i >= MAX_NR_IOREQ_SERVERS ) > goto fail; > > +ASSERT((internal && > +i >= MAX_NR_EXTERNAL_IOREQ_SERVERS && i < MAX_NR_IOREQ_SERVERS) > || > + (!internal && i < MAX_NR_EXTERNAL_IOREQ_SERVERS)); Perhaps easier to read both here and in the event the assertion would actually trigger as either ASSERT(internal ? i >= MAX_NR_EXTERNAL_IOREQ_SERVERS && i < MAX_NR_IOREQ_SERVERS : i < MAX_NR_EXTERNAL_IOREQ_SERVERS); or even ASSERT(i < MAX_NR_EXTERNAL_IOREQ_SERVERS ? !internal : internal && i < MAX_NR_IOREQ_SERVERS); ? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools: fix linking hypervisor includes to tools include directory
Ian Jackson writes ("Re: [PATCH] tools: fix linking hypervisor includes to
tools include directory"):
> Juergen Gross writes ("[PATCH] tools: fix linking hypervisor includes to
> tools include directory"):
> > An incremental build of tools/include won't pickup new hypervisor
> > headers in tools/include/xen. Fix that.
>
> I personally I think trying to get this kind of thing to work properly
> with recursive make is too hard to be worth trying. But I won't stand
> in your way.
>
> Acked-by: Ian Jackson
And committed.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxlu: Handle += in config files
Ian Jackson writes ("Re: [PATCH] libxlu: Handle += in config files"):
> Anthony PERARD writes ("Re: [PATCH] libxlu: Handle += in config files"):
> > I wonder if instead of doing += on all strings, we should instead have
> > `xl' whitelist the few options where += would make sense. (and at that
> > point, it would be easy to add a ' ' where is make sense, like
> > "cmdline"s. But then, how to tell users that it can't do "name+='-new'"?
> > because xlu would just print a warning, and xl would keep going with
> > name="". Try "xl create memory+=42" ;-).
>
> Do we really need to gold-plate it like this ? If someone tries to
> append to a string when it doesn't make sense the software will still
> do what they ought to have expected. And it doesn't seem like a
> likely kind of error.
>
> As for the original patch,
>
> Acked-by: Ian Jackson
I reread the thread and I think there were no blocking objections.
So I have pushed it.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 06/11] ioreq: allow dispatching ioreqs to internal servers
On 03.09.2019 18:14, Roger Pau Monne wrote:
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -1493,9 +1493,18 @@ int hvm_send_ioreq(ioservid_t id, ioreq_t *proto_p,
> bool buffered)
>
> ASSERT(s);
>
> +if ( hvm_ioreq_is_internal(id) && buffered )
> +{
> +ASSERT_UNREACHABLE();
> +return X86EMUL_UNHANDLEABLE;
> +}
> +
> if ( buffered )
> return hvm_send_buffered_ioreq(s, proto_p);
Perhaps better (to avoid yet another conditional on the non-
buffered path)
if ( buffered )
{
if ( likely(!hvm_ioreq_is_internal(id)) )
return hvm_send_buffered_ioreq(s, proto_p);
ASSERT_UNREACHABLE();
return X86EMUL_UNHANDLEABLE;
}
?
> +if ( hvm_ioreq_is_internal(id) )
> +return s->handler(curr, proto_p, s->data);
At this point I'm becoming curious what the significance of
ioreq_t's state field is for internal servers, as nothing was
said so far in this regard: Is it entirely unused? Is every
handler supposed to drive it? If so, what about return value
here and proto_p->state not really matching up? And if not,
shouldn't you update the field here, at the very least to
avoid any chance of confusing callers?
A possible consequence of the answers to this might be for
the hook's middle parameter to be constified (in patch 4).
Having said this, as a result of having looked at some of the
involved code, and with the cover letter not clarifying this,
what's the reason for going this seemingly more complicated
route, rather than putting vPCI behind the hvm_io_intercept()
machinery, just like is the case for other internal handling?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 141498: regressions - FAIL
flight 141498 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141498/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 141253 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen ce44fd015e55d0ecc47c160fb5ce69070aa4991b baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Last test of basis 141253 2019-09-12 17:00:43 Z7 days Failing since141255 2019-09-12 21:01:22 Z7 days 50 attempts Testing same since 141489 2019-09-20 01:02:25 Z0 days3 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Chao Gao Christian Lindig Daniel De Graaf Ian Jackson Jan Beulich Juergen Gross Julien Grall Oleksandr Tyshchenko Paul Durrant Pawel Wieczorkiewicz Roger Pau Monné Stefano Stabellini Stefano Stabellini Volodymyr Babchuk Wei Liu Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1029 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v12] x86/emulate: Send vm_event from emulate
A/D bit writes (on page walks) can be considered benign by an introspection
agent, so receiving vm_events for them is a pessimization. We try here to
optimize by filtering these events out.
Currently, we are fully emulating the instruction at RIP when the hardware sees
an EPT fault with npfec.kind != npfec_kind_with_gla. This is, however,
incorrect, because the instruction at RIP might legitimately cause an
EPT fault of its own while accessing a _different_ page from the original one,
where A/D were set.
The solution is to perform the whole emulation, while ignoring EPT restrictions
for the walk part, and taking them into account for the "actual" emulating of
the instruction at RIP. When we send out a vm_event, we don't want the emulation
to complete, since in that case we won't be able to veto whatever it is doing.
That would mean that we can't actually prevent any malicious activity, instead
we'd only be able to report on it.
When we see a "send-vm_event" case while emulating, we need to first send the
event out and then suspend the emulation (return X86EMUL_RETRY).
After the emulation stops we'll call hvm_vm_event_do_resume() again after the
introspection agent treats the event and resumes the guest. There, the
instruction at RIP will be fully emulated (with the EPT ignored) if the
introspection application allows it, and the guest will continue to run past
the instruction.
A common example is if the hardware exits because of an EPT fault caused by a
page walk, p2m_mem_access_check() decides if it is going to send a vm_event.
If the vm_event was sent and it would be treated so it runs the instruction
at RIP, that instruction might also hit a protected page and provoke a vm_event.
Now if npfec.kind == npfec_kind_in_gpt and
d->arch.monitor.inguest_pagefault_disabled
is true then we are in the page walk case and we can do this emulation
optimization
and emulate the page walk while ignoring the EPT, but don't ignore the EPT for
the
emulation of the actual instruction.
In the first case we would have 2 EPT events, in the second case we would have
1 EPT event if the instruction at the RIP triggers an EPT event.
We use hvmemul_map_linear_addr() to intercept write access and
__hvm_copy() to intercept exec, read and write access.
In order to have __hvm_copy() issue ~X86EMUL_RETRY a new return type,
HVMTRANS_need_retry, was added and all the places that consume HVMTRANS*
and needed adjustment where changed accordingly.
hvm_emulate_send_vm_event() can return false if there was no violation,
if there was an error from monitor_traps() or p2m_get_mem_access().
-ESRCH from p2m_get_mem_access() is treated as restricted access.
NOTE: hvm_emulate_send_vm_event() assumes the caller will enable/disable
arch.vm_event->send_event
Signed-off-by: Alexandru Isaila
---
Changes since V11:
- Rename HVMTRANS_bad_gfn_access to HVMTRANS_need_retry
- Check unlikely(v->arch.vm_event) first
- Move send_event disable from hvm_monitor_check_p2m() to the
caller
- Add the missing HVMTRANS_need_retry checks for HVMTRANS*
consumers.
---
xen/arch/x86/hvm/emulate.c| 18 ++-
xen/arch/x86/hvm/hvm.c| 9
xen/arch/x86/hvm/intercept.c | 2 +
xen/arch/x86/hvm/monitor.c| 78 +++
xen/arch/x86/mm/mem_access.c | 9 +++-
xen/arch/x86/mm/shadow/hvm.c | 1 +
xen/include/asm-x86/hvm/monitor.h | 3 ++
xen/include/asm-x86/hvm/support.h | 1 +
xen/include/asm-x86/vm_event.h| 2 +
9 files changed, 121 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 36bcb526d3..ee9b97f5b6 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -548,6 +548,7 @@ static void *hvmemul_map_linear_addr(
unsigned int nr_frames = ((linear + bytes - !!bytes) >> PAGE_SHIFT) -
(linear >> PAGE_SHIFT) + 1;
unsigned int i;
+gfn_t gfn;
/*
* mfn points to the next free slot. All used slots have a page reference
@@ -582,7 +583,7 @@ static void *hvmemul_map_linear_addr(
ASSERT(mfn_x(*mfn) == 0);
res = hvm_translate_get_page(curr, addr, true, pfec,
- &pfinfo, &page, NULL, &p2mt);
+ &pfinfo, &page, &gfn, &p2mt);
switch ( res )
{
@@ -601,6 +602,7 @@ static void *hvmemul_map_linear_addr(
case HVMTRANS_gfn_paged_out:
case HVMTRANS_gfn_shared:
+case HVMTRANS_need_retry:
err = ERR_PTR(~X86EMUL_RETRY);
goto out;
@@ -626,6 +628,14 @@ static void *hvmemul_map_linear_addr(
ASSERT(p2mt == p2m_ram_logdirty || !p2m_is_readonly(p2mt));
}
+
+if ( unlikely(curr->arch.vm_event) &&
+ curr->arch.vm_event->send_event &&
+ hvm_monitor_check_p2m(addr, gfn, pfec, npfec_kind_with_gla) )
+{
+err = ERR_PTR(~X86EMUL_RETRY);
+go
Re: [Xen-devel] [PATCH] libxc/x86: avoid overflow in CPUID APIC ID adjustments
On 20/09/2019 11:20, Jan Beulich wrote: > On 20.09.2019 12:05, Andrew Cooper wrote: >> On 19/09/2019 12:48, Jan Beulich wrote: >>> Recent AMD processors may report up to 128 logical processors in CPUID >>> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike), >>> as the respective field is only 8 bits wide. Suppress doubling the value >>> (and its leaf 0x8008 counterpart) in such a case. >>> >>> Additionally don't even do any adjustment when the host topology already >>> includes room for multiple threads per core. >>> >>> Furthermore don't double the Maximum Cores Per Package at all - by us >>> introducing a fake HTT effect, the core count doesn't need to change. >>> Instead adjust the Maximum Logical Processors Sharing Cache field, which >>> so far was zapped altogether. >>> >>> Also zap leaf 4 (and at the same time leaf 2) EDX output for AMD. >>> >>> Signed-off-by: Jan Beulich >>> --- >>> TBD: Using xc_physinfo() output here needs a better solution. The >>> threads_per_core value returned is the count of active siblings of >>> CPU 0, rather than a system wide applicable value (and constant >>> over the entire session). Using CPUID output (leaves 4 and >>> 801e) doesn't look viable either, due to this not really being >>> the host values on PVH. Judging from the host feature set's HTT >>> flag also wouldn't tell us whether there actually are multiple >>> threads per core. >> The key thing is that htt != "more than one thread per core". HTT is >> strictly a bit indicating that topology information is available in a >> new form in the CPUID leaves (or in AMDs case, the same information >> should be interpreted in a new way). Just because HTT is set (and it >> does get set in non-HT capable systems), doesn't mean there is space for >> more than thread per core in topology information. >> >> For PV guests, my adjustment in the CPUID series shows (what I believe >> to be) the only correct way of propagating the host HTT/CMP_LEGACY >> settings through. >> >> For HVM guests, it really shouldn't really have anything to do with the >> host setting. We should be choosing how many threads/core to give to >> the guest, then constructing the topology information from first principles. >> >> Ignore the PVH case. It is totally broken for several other reasons as >> well, and PVH Dom0 isn't a production-ready thing yet. >> >> This gets us back to the PV case where the host information is actually >> in view, and (for backport purposes) can be trusted. > Okay, this means I'll revive and finish the half cpuid() based attempt > I had made initially. A fundamental question remains open though from > your reply: Do you agree with the idea of avoiding the multiplication > by 2 if the host topology already provides at least one bit of thread > ID within the APIC ID? In theory, yes. In practice, I'd err on the side of not. A further problem with CPUID handling is that it is recalculated from scratch even after migrate. Therefore, any changes to the algorithm will cause inconsistencies to be seen in the guest across migrate/upgrade. This problem becomes substantially worse if the patch is backported to stable trees. Now that get_cpu_policy has existed for a little while, and set_cpu_policy is imminent, fixing the "CPUID changes across migrate" problem is almost doable, and is on the plan for toolstack work. That said, ultimately, anything "pre 4.14" => "4.14" is going to hit a discontinuity, because there is information discarded on the source side which can't be reconstructed on the destination. Overall, I would suggest doing the absolute minimum change required to unbreak Rome CPUs. Everything further is going to cause differences across migrate. In 4.14, I think we can reasonably fix all of: 1) CPUID data discarded for migrate 2) domain builder uses native CPUID 3) topology handling isn't consistent with SDM/APM all of which is libxc/libxl work, once set_cpu_policy() is in place. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 07/12] livepatch: Add per-function applied/reverted state tracking marker
> On 19. Sep 2019, at 17:18, Ross Lagerwall wrote:
>
> On 9/16/19 11:59 AM, Pawel Wieczorkiewicz wrote:
>> Livepatch only tracks an entire payload applied/reverted state. But,
>> with an option to supply the apply_payload() and/or revert_payload()
>> functions as optional hooks, it becomes possible to intermix the
>> execution of the original apply_payload()/revert_payload() functions
>> with their dynamically supplied counterparts.
>> It is important then to track the current state of every function
>> being patched and prevent situations of unintentional double-apply
>> or unapplied revert.
>> To support that, it is necessary to extend public interface of the
>> livepatch. The struct livepatch_func gets additional field holding
>> the applied/reverted state marker.
>> To reflect the livepatch payload ABI change, bump the version flag
>> LIVEPATCH_PAYLOAD_VERSION up to 2.
>> [And also update the top of the design document]
> snip> @@ -834,6 +839,8 @@ struct livepatch_func {
>> uint32_t old_size;
>> uint8_t version;/* MUST be LIVEPATCH_PAYLOAD_VERSION. */
>> uint8_t opaque[31];
>> +uint8_t applied;
>> +uint8_t _pad[7];
>> };
>> typedef struct livepatch_func livepatch_func_t;
>> #endif
>> diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
>> index 2aec532ee2..28f9536776 100644
>> --- a/xen/include/xen/livepatch.h
>> +++ b/xen/include/xen/livepatch.h
>> @@ -109,6 +109,31 @@ static inline int livepatch_verify_distance(const
>> struct livepatch_func *func)
>>return 0;
>> }
>> +
>> +static inline bool_t is_func_applied(const struct livepatch_func *func)
>
> Use bool rather than bool_t (throughout the patch).
>
ACK.
>> +{
>> +if ( func->applied == LIVEPATCH_FUNC_APPLIED )
>> +{
>> +printk(XENLOG_WARNING LIVEPATCH "%s: %s has been already applied
>> before\n",
>> +__func__, func->name);
>
> How about dropping this function and having a wrapper function like this:
>
> common_livepatch_apply() {
>if (func->applied == LIVEPATCH_FUNC_APPLIED) {
>WARN(...)
>return
>}
>
>arch_livepatch_apply()
>
>func->applied = LIVEPATCH_FUNC_APPLIED
> }
>
> This could be used by the normal apply code and any apply hooks.
>
> This avoids having duplicate code in each of the architectures that is not
> arch specific and also avoids having a state querying function emit a warning
> which seems odd to me.
>
Yes. That makes a lot of sense. Let me do that.
Thanks.
>> +return true;
>> +}
>> +
>> +return false;
>> +}
>> +
>> +static inline bool_t is_func_reverted(const struct livepatch_func *func)
>> +{
>> +if ( !func->old_addr || func->applied == LIVEPATCH_FUNC_NOT_APPLIED )
>> +{
>> +printk(XENLOG_WARNING LIVEPATCH "%s: %s has not been applied
>> before\n",
>> +__func__, func->name);
>> +return true;
>> +}
>> +
>> +return false;
>> +}
>> +
>> /*
>> * These functions are called around the critical region patching live code,
>> * for an architecture to take make appropratie global state adjustments.
>> @@ -117,7 +142,7 @@ int arch_livepatch_quiesce(void);
>> void arch_livepatch_revive(void);
>>
> --
> Ross Lagerwall
Best Regards,
Pawel Wieczorkiewicz
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V4 8/8] iommu/arm: Add Renesas IPMMU-VMSA support
On 20.09.19 03:25, Yoshihiro Shimoda wrote: Hi Oleksandr-san, Hi, Shimoda-san From: Oleksandr Tyshchenko, Sent: Saturday, September 14, 2019 12:35 AM From: Oleksandr Tyshchenko The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU) which provides address translation and access protection functionalities to processing units and interconnect networks. Please note, current driver is supposed to work only with newest R-Car Gen3 SoCs revisions which IPMMU hardware supports stage 2 translation table format and is able to use CPU's P2M table as is if one is 3-level page table (up to 40 bit IPA). The major differences compare to the Linux driver are: 1. Stage 1/Stage 2 translation. Linux driver supports Stage 1 translation only (with Stage 1 translation table format). It manages page table by itself. But Xen driver supports Stage 2 translation (with Stage 2 translation table format) to be able to share the P2M with the CPU. Stage 1 translation is always bypassed in Xen driver. So, Xen driver is supposed to be used with newest R-Car Gen3 SoC revisions only (H3 ES3.0, M3-W+, etc.) which IPMMU H/W supports stage 2 translation table format. 2. AArch64 support. Linux driver uses VMSAv8-32 mode, while Xen driver enables Armv8 VMSAv8-64 mode to cover up to 40 bit input address. 3. Context bank (sets of page table) usage. In Xen, each context bank is mapped to one Xen domain. So, all devices being pass throughed to the same Xen domain share the same context bank. 4. IPMMU device tracking. In Xen, all IOMMU devices are managed by single driver instance. So, driver uses global list to keep track of registered IPMMU devices. Signed-off-by: Oleksandr Tyshchenko CC: Julien Grall CC: Yoshihiro Shimoda Thank you for the patch. I have reviewed this patch about the IPMMU hardware bits, so, Reviewed-by: Yoshihiro Shimoda [for the IPMMU H/W bits] Thank you. ... I have checked new driver version on R-Car Gen3 M3N SoC and can confirm it works. -- Regards, Oleksandr Tyshchenko ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: iommu: Panic if not all IOMMUs are initialized
On 20.09.19 03:31, Stefano Stabellini wrote:
Hi, Stefano.
On Tue, 20 Aug 2019, Oleksandr wrote:
On 20.08.19 15:22, Julien Grall wrote:
Hi, Julien
-iommu_setup();
+rc = iommu_setup();
+if ( !iommu_enabled && rc != -ENODEV )
+panic("Couldn't configure correctly all the IOMMUs.");
Please add "\n"
You can add:
Tested-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
I added the "\n", fixed a typo in the commit message, and committed the
patch.
Thank you, I will re-base and drop dependency from the cover letter for
the coming V5 (IPMMU+iommu_fwspec).
--
Regards,
Oleksandr Tyshchenko
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] libxc/x86: avoid overflow in CPUID APIC ID adjustments
On 20.09.2019 14:40, Andrew Cooper wrote: > Overall, I would suggest doing the absolute minimum change required to > unbreak Rome CPUs. Well, okay, I'm zapping everything else, but it feels wrong to leave in place the similar overflow in intel_xc_cpuid_policy(). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V4 7/8] iommu/arm: Introduce iommu_add_dt_device API
On 19/09/2019 14:26, Oleksandr wrote: On 19.09.19 15:29, Julien Grall wrote: Hi, Hi, Julien Hi, + +int __init iommu_add_dt_device(struct dt_device_node *np) Sorry to only realise it now. Would it make sense to have this function implemented in xen/passthrough/device_tree.c? Not entirely sure. device_tree.c is a common code. The iommu_fwspec stuff (widely used in this function) is ARM code. Some of the device_tree.c already contains Arm specific code (such as device.h). DT has been only used by Arm so far, so it is sadly fairly tie to the architecture. But it should be easy to make it generic if needs be (such as for RISCv). While iommu_fwspec is been implemented in Arm headers, this could potentially be made common. So I would still prefer this that function is moved in device_tree.c Well, will move. Also I will remove __init as it can be called at runtime... As for runtime: The current implementation allows us to fail at early stage if something is wrong with the device which is behind an IOMMU (and needs to be protected). As we scan for all present devices, but not only for "passthrough". The "splitting" into handle_device() for hwdom and iommu_do_dt_domctl() for other guests will postpone an error recognition to the guest domain creation time. So, we would have non function system anyway. Wouldn't be better to fail early instead of continue and fail anyway? Yes your implementation allows us to fail at early stage but then you are abusing the function handle_device(). There are actually no promise this will be called for every device going forward. Think about dom0less where the goal is to have no dom0 at all. You are also tying the order of the domains creation as dom0 would have to be always created before any other domains are created. Similar (ab)use of handle_device() does not exist, so I would rather not start to introduce them because this will become quickly unmaintainable as we are mixing dom0 creation and Xen initialization. Even without this series, assigning a device to the guest may not be a success because the IOMMU may not have enough context bank (used for configuring the IOMMU stage-2) or there are not enough memory. Not been able to add the device to the IOMMU driver is only another example where it may fail. But I would not consider this as not functional. The rest of your system may work perfectly even if this particular device is not usable. There are no security risk as the IOMMU should block any transaction by default. I am also not in favor of parsing again the Device-Tree (we have enough of them), so this is the best solution I can come up. Feel free to suggest something different. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V4 7/8] iommu/arm: Introduce iommu_add_dt_device API
Hi Julien + +int __init iommu_add_dt_device(struct dt_device_node *np) Sorry to only realise it now. Would it make sense to have this function implemented in xen/passthrough/device_tree.c? Not entirely sure. device_tree.c is a common code. The iommu_fwspec stuff (widely used in this function) is ARM code. Some of the device_tree.c already contains Arm specific code (such as device.h). DT has been only used by Arm so far, so it is sadly fairly tie to the architecture. But it should be easy to make it generic if needs be (such as for RISCv). While iommu_fwspec is been implemented in Arm headers, this could potentially be made common. So I would still prefer this that function is moved in device_tree.c Well, will move. Also I will remove __init as it can be called at runtime... As for runtime: The current implementation allows us to fail at early stage if something is wrong with the device which is behind an IOMMU (and needs to be protected). As we scan for all present devices, but not only for "passthrough". The "splitting" into handle_device() for hwdom and iommu_do_dt_domctl() for other guests will postpone an error recognition to the guest domain creation time. So, we would have non function system anyway. Wouldn't be better to fail early instead of continue and fail anyway? Yes your implementation allows us to fail at early stage but then you are abusing the function handle_device(). There are actually no promise this will be called for every device going forward. Think about dom0less where the goal is to have no dom0 at all. You are also tying the order of the domains creation as dom0 would have to be always created before any other domains are created. Similar (ab)use of handle_device() does not exist, so I would rather not start to introduce them because this will become quickly unmaintainable as we are mixing dom0 creation and Xen initialization. Even without this series, assigning a device to the guest may not be a success because the IOMMU may not have enough context bank (used for configuring the IOMMU stage-2) or there are not enough memory. Not been able to add the device to the IOMMU driver is only another example where it may fail. But I would not consider this as not functional. The rest of your system may work perfectly even if this particular device is not usable. There are no security risk as the IOMMU should block any transaction by default. I am also not in favor of parsing again the Device-Tree (we have enough of them), so this is the best solution I can come up. Feel free to suggest something different. I am happy with the explanation, sounds reasonable. Will modify patch as you suggested. -- Regards, Oleksandr Tyshchenko ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 141481: all pass - PUSHED
flight 141481 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/141481/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 85ccbee2abf4ac9ed006409d1b02a3bdd660261c baseline version: ovmf b0c15fb128c518b9acd8611a2deea213e9e55193 Last test of basis 141451 2019-09-19 01:09:48 Z1 days Testing same since 141481 2019-09-19 19:13:57 Z0 days1 attempts People who touched revisions under test: Fan, ZhijuX Michael Johnson Ray Ni Zhiju.Fan jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git b0c15fb128..85ccbee2ab 85ccbee2abf4ac9ed006409d1b02a3bdd660261c -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2] libxc/x86: avoid overflow in CPUID APIC ID adjustments
Recent AMD processors may report up to 128 logical processors in CPUID
leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
as the respective field is only 8 bits wide. Suppress doubling the value
(and its leaf 0x8008 counterpart) in such a case.
Note that while there's a similar overflow in intel_xc_cpuid_policy(),
that one is being left alone for now.
Note further that while it was considered to suppress the multiplication
by 2 altogether if the host topology already provides at least one bit
of thread ID within APIC IDs, it was decided to avoid more change here
than really needed at this point.
Also zap leaf 4 (and at the same time leaf 2) EDX output for AMD, as it
should have been from the beginning.
Signed-off-by: Jan Beulich
---
v2: Drop use of physinfo. Drop Intel-only leaf 4 change. Increment
ApicIdCoreSize only when doubling NumberOfCores.
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -385,7 +385,7 @@ static void amd_xc_cpuid_policy(const st
{
case 0x0002:
case 0x0004:
-regs[0] = regs[1] = regs[2] = 0;
+regs[0] = regs[1] = regs[2] = regs[3] = 0;
break;
case 0x8000:
@@ -395,11 +395,20 @@ static void amd_xc_cpuid_policy(const st
case 0x8008:
/*
- * ECX[15:12] is ApicIdCoreSize: ECX[7:0] is NumberOfCores (minus one).
- * Update to reflect vLAPIC_ID = vCPU_ID * 2.
+ * ECX[15:12] is ApicIdCoreSize.
+ * ECX[7:0] is NumberOfCores (minus one).
+ * Update to reflect vLAPIC_ID = vCPU_ID * 2. But make sure to avoid
+ * - overflow,
+ * - going out of sync with leaf 1 EBX[23:16],
+ * - incrementing ApicIdCoreSize when it's zero (which changes the
+ * meaning of bits 7:0).
*/
-regs[2] = ((regs[2] + (1u << 12)) & 0xf000u) |
- ((regs[2] & 0xffu) << 1) | 1u;
+if ( (regs[2] & 0x7fu) < 0x7fu )
+{
+if ( (regs[2] & 0xf000u) && (regs[2] & 0xf000u) != 0xf000u )
+regs[2] = ((regs[2] + 0x1000u) & 0xf000u) | (regs[2] & 0xffu);
+regs[2] = (regs[2] & 0xf000u) | ((regs[2] & 0x7fu) << 1) | 1u;
+}
break;
case 0x800a: {
@@ -478,9 +487,13 @@ static void xc_cpuid_hvm_policy(const st
case 0x0001:
/*
* EBX[23:16] is Maximum Logical Processors Per Package.
- * Update to reflect vLAPIC_ID = vCPU_ID * 2.
+ * Update to reflect vLAPIC_ID = vCPU_ID * 2, but make sure to avoid
+ * overflow.
*/
-regs[1] = (regs[1] & 0xu) | ((regs[1] & 0x007fu) << 1);
+if ( !(regs[1] & 0x0080u) )
+regs[1] = (regs[1] & 0xu) | ((regs[1] & 0x007fu) << 1);
+else
+regs[1] &= 0x00ffu;
regs[2] = info->featureset[featureword_of(X86_FEATURE_SSE3)];
regs[3] = (info->featureset[featureword_of(X86_FEATURE_FPU)] |
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] libxc/x86: avoid overflow in CPUID APIC ID adjustments
On 20.09.2019 15:54, Jan Beulich wrote: > Recent AMD processors may report up to 128 logical processors in CPUID > leaf 1. Doubling this value produces 0 (which OSes sincerely dislike), > as the respective field is only 8 bits wide. Suppress doubling the value > (and its leaf 0x8008 counterpart) in such a case. > > Note that while there's a similar overflow in intel_xc_cpuid_policy(), > that one is being left alone for now. > > Note further that while it was considered to suppress the multiplication > by 2 altogether if the host topology already provides at least one bit > of thread ID within APIC IDs, it was decided to avoid more change here > than really needed at this point. Given this I've just changed the title to "avoid certain overflows in CPUID APIC ID adjustments". Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: d013cc800a2a41b0496f99a11f3cff724cf65941 Bug not present: 9e0babf2c06c73cda2c0cd37a1653d823adb40ec Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/141509/ (Revision log too long, omitted.) For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow.xen-boot --summary-out=tmp/141509.bisection-summary --basis-template=133580 --blessings=real,real-bisect linux-linus test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow xen-boot Searching for failure / basis pass: 141446 fail [host=italia1] / 138849 [host=chardonnay1] 138813 [host=albana1] 138780 [host=baroque1] 138754 [host=debina1] 138735 [host=debina0] 138710 [host=elbling1] 138680 [host=pinot0] 138661 [host=albana0] 138639 [host=italia0] 138612 [host=fiano0] 138584 [host=rimava1] 138488 [host=chardonnay0] 138386 [host=albana1] 138245 [host=chardonnay1] 138073 [host=pinot1] 137986 [host=baroque1] 137896 ok. Failure / basis pass flights: 141446 / 137896 (tree with no url: minios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest d013cc800a2a41b0496f99a11f3cff724cf65941 c530a75c1e6a472b0eb9558310b518f0dfcd8860 82c1a2120855e7fe32417870910f4ce20dca97a3 d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 43f5df79dad6738d52ea79d072de2b56eb96a91f 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Basis pass 9e0babf2c06c73cda2c0cd37a1653d823adb40ec c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0663641c977f97bef785c86978603c3a31a3d1c d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 85137fb5f2dfa5f83e9e340ca881c634ae14d4e9 36a1c7c213e13eb64d2c2d8aa9c5c805fe19020a Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#9e0babf2c06c73cda2c0cd37a1653d823adb40ec-d013cc800a2a41b0496f99a11f3cff724cf65941 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#b0663641c977f97bef785c86978603c3a31a3d1c-82c1a2120855e7fe32417870910f4ce20dca97a3 git://xenbits.xen.org/qemu-xen-traditional.\ git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-cef9660618a880ced798375a0fd16a8ad80bd0f0 git://xenbits.xen.org/osstest/seabios.git#85137fb5f2dfa5f83e9e340ca881c634ae14d4e9-43f5df79dad6738d52ea79d072de2b56eb96a91f git://xenbits.xen.org/xen.git#36a1c7c213e13eb64d2c2d8aa9c5c805fe19020a-1014f47c7a808e025b8920ab80bfe73a2888b3e5 adhoc-revtuple-generator: tree discontiguous: linux-2.6 From git://cache:9419/git://xenbits.xen.org/osstest/ovmf b0c15fb128..85ccbee2ab xen-tested-master -> origin/xen-tested-master adhoc-revtuple-generator: tree discontiguous: qemu-xen Loaded 3003 nodes in revision graph Searching for test results: 137739 [host=elbling1] 137896 pass 9e0babf2c06c73cda2c0cd37a1653d823adb40ec c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0663641c977f97bef785c86978603c3a31a3d1c d0d8ad39ecb51cd7497cd524484fe09f50876798 9cca02d8ffc23e9688a971d858e4ffdff5389b11 85137fb5f2dfa5f83e9e340ca881c634ae14d4e9 36a1c7c213e13eb64d2c2d8aa9c5c805fe19020a 137986 [host=baroque1] 138073 [host=pinot1] 138245 [host=chardonnay1] 138386 [host=albana1] 138488 [host=chardonnay0] 138584 [host=rimava1] 138612 [host=fiano0] 138639 [host=italia0] 138661 [host=albana0] 138680 [host=pinot0] 138710 [host=elbling1] 138735 [host=debina0] 138754 [host=debina1] 138780 [host=baroque1] 138813 [host=albana1] 138849 [host=chardonnay1] 138878 fail irrel
Re: [Xen-devel] [PATCH v12] x86/emulate: Send vm_event from emulate
On 20.09.2019 14:16, Alexandru Stefan ISAILA wrote:
> In order to have __hvm_copy() issue ~X86EMUL_RETRY a new return type,
> HVMTRANS_need_retry, was added and all the places that consume HVMTRANS*
> and needed adjustment where changed accordingly.
This is wrong and hence confusing: __hvm_copy() would never return
~X86EMUL_RETRY. In fact I think you've confused yourself enough to
make a questionable (possibly resulting) change:
> @@ -582,7 +583,7 @@ static void *hvmemul_map_linear_addr(
> ASSERT(mfn_x(*mfn) == 0);
>
> res = hvm_translate_get_page(curr, addr, true, pfec,
> - &pfinfo, &page, NULL, &p2mt);
> + &pfinfo, &page, &gfn, &p2mt);
This function ...
> switch ( res )
> {
> @@ -601,6 +602,7 @@ static void *hvmemul_map_linear_addr(
>
> case HVMTRANS_gfn_paged_out:
> case HVMTRANS_gfn_shared:
> +case HVMTRANS_need_retry:
... can't return this value, so you should omit this addition,
letting the new return value go through "default:".
> @@ -1852,6 +1864,8 @@ static int hvmemul_rep_movs(
>
> xfree(buf);
>
> +ASSERT(rc != HVMTRANS_need_retry);
> +
> if ( rc == HVMTRANS_gfn_paged_out )
> return X86EMUL_RETRY;
> if ( rc == HVMTRANS_gfn_shared )
> @@ -1964,6 +1978,8 @@ static int hvmemul_rep_stos(
> if ( buf != p_data )
> xfree(buf);
>
> +ASSERT(rc != HVMTRANS_need_retry);
> +
> switch ( rc )
> {
> case HVMTRANS_gfn_paged_out:
Looking at this again, I think it would better be an addition to
the switch() (using ASSERT_UNREACHABLE()). Generally this is
true for the rep_movs case as well, but that one would first
need converting to switch(), which I agree is beyond the scope
of this change. In both cases a brief comment would seem
worthwhile adding, clarifying that the new return value can
result from hvm_copy_*_guest_linear() only. This might become
relevant in particular if, down the road, we invent more cases
where HVMTRANS_need_retry is produced.
Then again maybe switching rep_movs to switch() would still be
a good thing to do here: Don't you agree that from an abstract
pov in both cases above X86EMUL_RETRY should be produced, if at
a future point physical accesses could also produce
HVMTRANS_need_retry? With this retaining the assertions is
certainly an option, but I think the fallback return value for
this case should still be X86EMUL_RETRY.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 23/47] xen/sched: switch sched_move_irqs() to take sched_unit as parameter
On 14.09.2019 10:52, Juergen Gross wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -474,12 +474,20 @@ int sched_init_vcpu(struct vcpu *v)
> return 0;
> }
>
> -static void sched_move_irqs(struct vcpu *v)
> +static void vcpu_move_irqs(struct vcpu *v)
> {
> arch_move_irqs(v);
> evtchn_move_pirqs(v);
> }
>
> +static void sched_move_irqs(struct sched_unit *unit)
I think the parameter could be constified.
> @@ -1736,7 +1744,7 @@ static void schedule(void)
> stop_timer(&prev->vcpu_list->periodic_timer);
>
> if ( next_slice.migrated )
> -sched_move_irqs(next->vcpu_list);
> +vcpu_move_irqs(next->vcpu_list);
Why is this not also sched_move_irqs(), at which point there wouldn't
be a need for a separate vcpu_move_irqs() afaict?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 141508: regressions - trouble: blocked/fail
flight 141508 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141508/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 141253 build-amd64 6 xen-buildfail REGR. vs. 141253 build-armhf 6 xen-buildfail REGR. vs. 141253 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen a30910bfd71a64895f0d6ddbb301cf1b5ed6c2f4 baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Last test of basis 141253 2019-09-12 17:00:43 Z7 days Failing since141255 2019-09-12 21:01:22 Z7 days 51 attempts Testing same since 141508 2019-09-20 13:00:42 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Chao Gao Christian Lindig Daniel De Graaf Ian Jackson Jan Beulich Juergen Gross Julien Grall Oleksandr Tyshchenko Paul Durrant Pawel Wieczorkiewicz Roger Pau Monné Stefano Stabellini Stefano Stabellini Volodymyr Babchuk Wei Liu Wei Liu jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1732 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v12] x86/emulate: Send vm_event from emulate
On 20.09.2019 17:22, Jan Beulich wrote:
> On 20.09.2019 14:16, Alexandru Stefan ISAILA wrote:
>> In order to have __hvm_copy() issue ~X86EMUL_RETRY a new return type,
>> HVMTRANS_need_retry, was added and all the places that consume HVMTRANS*
>> and needed adjustment where changed accordingly.
>
> This is wrong and hence confusing: __hvm_copy() would never return
> ~X86EMUL_RETRY. In fact I think you've confused yourself enough to
> make a questionable (possibly resulting) change:
The idea was to get X86EMUL_RETRY down the line from __hvm_copy().
I will adjust this.
>
>> @@ -582,7 +583,7 @@ static void *hvmemul_map_linear_addr(
>> ASSERT(mfn_x(*mfn) == 0);
>>
>> res = hvm_translate_get_page(curr, addr, true, pfec,
>> - &pfinfo, &page, NULL, &p2mt);
>> + &pfinfo, &page, &gfn, &p2mt);
>
> This function ...
>
>> switch ( res )
>> {
>> @@ -601,6 +602,7 @@ static void *hvmemul_map_linear_addr(
>>
>> case HVMTRANS_gfn_paged_out:
>> case HVMTRANS_gfn_shared:
>> +case HVMTRANS_need_retry:
>
> ... can't return this value, so you should omit this addition,
> letting the new return value go through "default:".
It is very clear that HVMTRANS_need_retry will not be returned form that
function. At least for now. I thought you wanted to have every possible
case covered in the switch. I can remove that case, there is not problem
here because, like I've said, it will never enter that case.
But as you said later work with HVMTRANS_need_retry will result in
returning X86EMUL_RETRY. Any way it's your call if I should remove it or
not.
>
>> @@ -1852,6 +1864,8 @@ static int hvmemul_rep_movs(
>>
>> xfree(buf);
>>
>> +ASSERT(rc != HVMTRANS_need_retry);
>> +
>> if ( rc == HVMTRANS_gfn_paged_out )
>> return X86EMUL_RETRY;
>> if ( rc == HVMTRANS_gfn_shared )
>> @@ -1964,6 +1978,8 @@ static int hvmemul_rep_stos(
>> if ( buf != p_data )
>> xfree(buf);
>>
>> +ASSERT(rc != HVMTRANS_need_retry);
>> +
>> switch ( rc )
>> {
>> case HVMTRANS_gfn_paged_out:
>
> Looking at this again, I think it would better be an addition to
> the switch() (using ASSERT_UNREACHABLE()). Generally this is
> true for the rep_movs case as well, but that one would first
> need converting to switch(), which I agree is beyond the scope
I agree that this is beyond the scope of this patch but it's not that
big of a change and it can be done.
But isn't having a default ASSERT_UNREACHABLE(); in both switch cases
change the behavior of the function?
> of this change. In both cases a brief comment would seem
> worthwhile adding, clarifying that the new return value can
> result from hvm_copy_*_guest_linear() only. This might become
> relevant in particular if, down the road, we invent more cases
> where HVMTRANS_need_retry is produced.
Is this comment aimed for the commit message or another place?
>
> Then again maybe switching rep_movs to switch() would still be
> a good thing to do here: Don't you agree that from an abstract
> pov in both cases above X86EMUL_RETRY should be produced, if at
> a future point physical accesses could also produce
> HVMTRANS_need_retry? With this retaining the assertions is
> certainly an option, but I think the fallback return value for
> this case should still be X86EMUL_RETRY.
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 24/47] xen: switch from for_each_vcpu() to for_each_sched_unit()
On 14.09.2019 10:52, Juergen Gross wrote:
> @@ -508,25 +515,27 @@ int sched_move_domain(struct domain *d, struct cpupool
> *c)
> if ( IS_ERR(domdata) )
> return PTR_ERR(domdata);
>
> -vcpu_priv = xzalloc_array(void *, d->max_vcpus);
> -if ( vcpu_priv == NULL )
> +/* TODO: fix array size with multiple vcpus per unit. */
> +unit_priv = xzalloc_array(void *, d->max_vcpus);
> +if ( unit_priv == NULL )
> {
> sched_free_domdata(c->sched, domdata);
> return -ENOMEM;
> }
>
> -for_each_vcpu ( d, v )
> +unit_idx = 0;
> +for_each_sched_unit ( d, unit )
> {
> -vcpu_priv[v->vcpu_id] = sched_alloc_vdata(c->sched, v->sched_unit,
> - domdata);
> -if ( vcpu_priv[v->vcpu_id] == NULL )
> +unit_priv[unit_idx] = sched_alloc_vdata(c->sched, unit, domdata);
> +if ( unit_priv[unit_idx] == NULL )
> {
> -for_each_vcpu ( d, v )
> -xfree(vcpu_priv[v->vcpu_id]);
> -xfree(vcpu_priv);
> +for ( unit_idx = 0; unit_priv[unit_idx]; unit_idx++ )
> +sched_free_vdata(c->sched, unit_priv[unit_idx]);
This is an unexpected change from xfree() to sched_free_vdata(). If
it really is correct, it should be mentioned in the description. I
can see why this might be better from an abstract pov, but it's
questionable whether arinc653's update_schedule_vcpus() really wants
calling at this point (perhaps it does, as a653sched_alloc_vdata()
also calls it).
Josh, Robert: Besides this immediate aspect I also wonder whether
said call is correct to make outside of a sched_priv->lock'ed
region, when both other instances occur inside of one (and in one
case immediately before an unlock, i.e. if the lock wasn't needed
the two steps could well be re-ordered).
Finally, at this point, shouldn't the functions and hooks (already)
be named {alloc,free}_udata()?
> @@ -896,18 +929,22 @@ void restore_vcpu_affinity(struct domain *d)
> cpupool_domain_cpumask(d));
> if ( cpumask_empty(cpumask_scratch_cpu(cpu)) )
> {
> -if ( v->affinity_broken )
> +if ( sched_check_affinity_broken(unit) )
> {
> -sched_set_affinity(v, unit->cpu_hard_affinity_saved, NULL);
> -v->affinity_broken = 0;
> +/* Affinity settings of one vcpu are for the complete unit.
> */
> +sched_set_affinity(unit->vcpu_list,
> + unit->cpu_hard_affinity_saved, NULL);
Yet despite the comment the function gets passed a struct vcpu *,
and this doesn't look to change by the end of the series. Is there
a reason for this?
> @@ -950,17 +986,19 @@ int cpu_disable_scheduler(unsigned int cpu)
>
> for_each_domain_in_cpupool ( d, c )
> {
> -for_each_vcpu ( d, v )
> +struct sched_unit *unit;
> +
> +for_each_sched_unit ( d, unit )
> {
> unsigned long flags;
> -struct sched_unit *unit = v->sched_unit;
> spinlock_t *lock = unit_schedule_lock_irqsave(unit, &flags);
>
> cpumask_and(&online_affinity, unit->cpu_hard_affinity,
> c->cpu_valid);
> if ( cpumask_empty(&online_affinity) &&
> cpumask_test_cpu(cpu, unit->cpu_hard_affinity) )
> {
> -if ( v->affinity_broken )
> +/* TODO: multiple vcpus per unit. */
> +if ( unit->vcpu_list->affinity_broken )
Why not sched_check_affinity_broken(unit)? Quite possibly this would
make the TODO item unnecessary?
> @@ -968,14 +1006,15 @@ int cpu_disable_scheduler(unsigned int cpu)
> break;
> }
>
> -printk(XENLOG_DEBUG "Breaking affinity for %pv\n", v);
> +printk(XENLOG_DEBUG "Breaking affinity for %pv\n",
> + unit->vcpu_list);
>
> -sched_set_affinity(v, &cpumask_all, NULL);
> +sched_set_affinity(unit->vcpu_list, &cpumask_all, NULL);
> }
>
> -if ( v->processor != cpu )
> +if ( sched_unit_cpu(unit) != sched_get_resource_cpu(cpu) )
Didn't you agree that this can be had cheaper? Quite likely my v2
review remark was on a different instance, but the pattern ought
to be relatively simple to find in the entire series (and by the
end of the series there's one other instance in schedule.c ...
> @@ -988,17 +1027,18 @@ int cpu_disable_scheduler(unsigned int cpu)
> * * the scheduler will always find a suitable solution, or
> *things would have failed before getting in here.
> */
> -vcpu_migrate_start(v);
> +/* TODO: multiple vcpus per unit. */
> +vcpu_migrate_start(unit->vcpu_list);
> unit_schedule_unlock_irqrestore(lock, flags, unit);
>
> -
Re: [Xen-devel] [xen-unstable-smoke test] 141508: regressions - trouble: blocked/fail
On 20.09.2019 16:45, osstest service owner wrote: > flight 141508 xen-unstable-smoke real [real] > http://logs.test-lab.xenproject.org/osstest/logs/141508/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-arm64-xsm 6 xen-buildfail REGR. vs. > 141253 > build-amd64 6 xen-buildfail REGR. vs. > 141253 Just FYI, in case you didn't notice yet: CC xenlight_stubs.o xenlight_stubs.c: In function 'stub_libxl_domain_pause': xenlight_stubs.c:632:8: error: too few arguments to function 'libxl_domain_pause' ret = libxl_domain_pause(CTX, c_domid); ^~ In file included from xenlight_stubs.c:30:0: /home/osstest/build.141508.build-amd64/xen/tools/ocaml/libs/xl/../../../../tools/libxl/libxl.h:1643:5: note: declared here int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid, ^~ xenlight_stubs.c: In function 'stub_libxl_domain_unpause': xenlight_stubs.c:648:8: error: too few arguments to function 'libxl_domain_unpause' ret = libxl_domain_unpause(CTX, c_domid); ^~~~ In file included from xenlight_stubs.c:30:0: /home/osstest/build.141508.build-amd64/xen/tools/ocaml/libs/xl/../../../../tools/libxl/libxl.h:1646:5: note: declared here int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid, ^~~~ xenlight_stubs.c: In function 'stub_xl_send_trigger': xenlight_stubs.c:1045:8: error: too few arguments to function 'libxl_send_trigger' ret = libxl_send_trigger(CTX, c_domid, c_trigger, c_vcpuid); ^~ In file included from xenlight_stubs.c:30:0: /home/osstest/build.141508.build-amd64/xen/tools/ocaml/libs/xl/../../../../tools/libxl/libxl.h:2408:5: note: declared here int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid, ^~ /home/osstest/build.141508.build-amd64/xen/tools/ocaml/libs/xl/../../Makefile.rules:37: recipe for target 'xenlight_stubs.o' failed make[7]: Leaving directory '/home/osstest/build.141508.build-amd64/xen/tools/ocaml/libs/xl' make[7]: *** [xenlight_stubs.o] Error 1 Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early
On Fri, 20 Sep 2019, Julien Grall wrote:
> On 20/09/2019 00:37, Stefano Stabellini wrote:
> > On Tue, 17 Sep 2019, Julien Grall wrote:
> > > The current implementations of xen_{map, unmap}_table() expect
> > > {map, unmap}_domain_page() to be usable. Those helpers are used to
> > > map/unmap page tables while update Xen page-tables.
> > >
> > > Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT update in
> > > {set, clear}_fixmap()", setup_fixmap() will make use of the helpers
> > > mentioned above. When booting Xen using GRUB, setup_fixmap() may be used
> > > before map_domain_page() can be called. This will result to data abort:
> > >
> > > (XEN) Data Abort Trap. Syndrome=0x5
> > > (XEN) CPU0: Unexpected Trap: Data Abort
> > >
> > > [...]
> > >
> > > (XEN) Xen call trace:
> > > (XEN)[<0025ab6c>] mm.c#xen_pt_update+0x2b4/0x59c (PC)
> > > (XEN)[<0025ab20>] mm.c#xen_pt_update+0x268/0x59c (LR)
> > > (XEN)[<0025ae70>] set_fixmap+0x1c/0x2c
> > > (XEN)[<002a9c98>] copy_from_paddr+0x7c/0xdc
> > > (XEN)[<002a4ae0>] has_xsm_magic+0x18/0x34
> > > (XEN)[<002a5b5c>] bootfdt.c#early_scan_node+0x398/0x560
> > > (XEN)[<002a5de0>] device_tree_for_each_node+0xbc/0x144
> > > (XEN)[<002a5ed4>] boot_fdt_info+0x6c/0x260
> > > (XEN)[<002ac0d0>] start_xen+0x108/0xc74
> > > (XEN)[<0020044c>] arm64/head.o#paging+0x60/0x88
> > >
> > > During early boot, the page tables are either statically allocated in
> > > Xen binary or allocated via alloc_boot_pages().
> > >
> > > For statically allocated page-tables, they will already be mapped as
> > > part of Xen binary. So we can easily find the virtual address.
> > >
> > > For dynamically allocated page-tables, we need to rely
> > > map_domain_page() to be functionally working.
> > >
> > > For arm32, the call will be usable much before page can be dynamically
> > > allocated (see setup_pagetables()). For arm64, the call will be usable
> > > after setup_xenheap_mappings().
> > >
> > > In both cases, memory are given to the boot allocator afterwards. So we
> > > can rely on map_domain_page() for mapping page tables allocated
> > > dynamically.
> > >
> > > The helpers xen_{map, unmap}_table() are now updated to take into
> > > account the case where page-tables are part of Xen binary.
> > >
> > > Fixes: 022387ee1a ('xen/arm: mm: Don't open-code Xen PT update in {set,
> > > clear}_fixmap()')
> > > Signed-off-by: Julien Grall
> > > ---
> > > xen/arch/arm/mm.c | 20
> > > 1 file changed, 20 insertions(+)
> > >
> > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > > index e1cdeaaf2f..da6303a8fd 100644
> > > --- a/xen/arch/arm/mm.c
> > > +++ b/xen/arch/arm/mm.c
> > > @@ -950,11 +950,31 @@ static int create_xen_table(lpae_t *entry)
> > > static lpae_t *xen_map_table(mfn_t mfn)
> > > {
> > > +/*
> > > + * We may require to map the page table before map_domain_page() is
> > > + * useable. The requirements here is it must be useable as soon as
> > > + * page-tables are allocated dynamically via alloc_boot_pages().
> > > + */
> > > +if ( system_state == SYS_STATE_early_boot )
> > > +{
> > > +vaddr_t va = mfn_to_maddr(mfn) - phys_offset;
> > > +
> > > +if ( is_kernel(va) )
> > > +return (lpae_t *)va;
> >
> > Is it intended to continue if it is not a xen text page? Shouldn't we
> > BUG() or WARN?
> Yes, I wrote the rationale in the commit message and a summary in a few lines
> above. For convenience, I pasted the commit message again here:
The commit message explains what you are doing but I am still missing
something.
Why are we continuing if system_state == SYS_STATE_early_boot and
!is_kernel(va)?
The commit message explains that if system_state == SYS_STATE_early_boot
pagetable pages are static, right? Only after dynamic allocation are
possible it makes sense to use map_domain_page, and dynamic allocations
are possible roughly when system_state switched to SYS_STATE_boot.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v12] x86/emulate: Send vm_event from emulate
On 20.09.2019 16:59, Alexandru Stefan ISAILA wrote:
>
>
> On 20.09.2019 17:22, Jan Beulich wrote:
>> On 20.09.2019 14:16, Alexandru Stefan ISAILA wrote:
>>> In order to have __hvm_copy() issue ~X86EMUL_RETRY a new return type,
>>> HVMTRANS_need_retry, was added and all the places that consume HVMTRANS*
>>> and needed adjustment where changed accordingly.
>>
>> This is wrong and hence confusing: __hvm_copy() would never return
>> ~X86EMUL_RETRY. In fact I think you've confused yourself enough to
>> make a questionable (possibly resulting) change:
>
> The idea was to get X86EMUL_RETRY down the line from __hvm_copy().
> I will adjust this.
>
>>
>>> @@ -582,7 +583,7 @@ static void *hvmemul_map_linear_addr(
>>> ASSERT(mfn_x(*mfn) == 0);
>>>
>>> res = hvm_translate_get_page(curr, addr, true, pfec,
>>> - &pfinfo, &page, NULL, &p2mt);
>>> + &pfinfo, &page, &gfn, &p2mt);
>>
>> This function ...
>>
>>> switch ( res )
>>> {
>>> @@ -601,6 +602,7 @@ static void *hvmemul_map_linear_addr(
>>>
>>> case HVMTRANS_gfn_paged_out:
>>> case HVMTRANS_gfn_shared:
>>> +case HVMTRANS_need_retry:
>>
>> ... can't return this value, so you should omit this addition,
>> letting the new return value go through "default:".
>
> It is very clear that HVMTRANS_need_retry will not be returned form that
> function. At least for now. I thought you wanted to have every possible
> case covered in the switch. I can remove that case, there is not problem
> here because, like I've said, it will never enter that case.
>
> But as you said later work with HVMTRANS_need_retry will result in
> returning X86EMUL_RETRY. Any way it's your call if I should remove it or
> not.
The result should be consistent (i.e. between the case here
and the rep_movs / rep_stos cases below). Overall I think it
would be cleanest if in all three cases an ASSERT_UNREACHABLE()
fell through to a "return X86EMUL_RETRY;".
>>> @@ -1852,6 +1864,8 @@ static int hvmemul_rep_movs(
>>>
>>> xfree(buf);
>>>
>>> +ASSERT(rc != HVMTRANS_need_retry);
>>> +
>>> if ( rc == HVMTRANS_gfn_paged_out )
>>> return X86EMUL_RETRY;
>>> if ( rc == HVMTRANS_gfn_shared )
>>> @@ -1964,6 +1978,8 @@ static int hvmemul_rep_stos(
>>> if ( buf != p_data )
>>> xfree(buf);
>>>
>>> +ASSERT(rc != HVMTRANS_need_retry);
>>> +
>>> switch ( rc )
>>> {
>>> case HVMTRANS_gfn_paged_out:
>>
>> Looking at this again, I think it would better be an addition to
>> the switch() (using ASSERT_UNREACHABLE()). Generally this is
>> true for the rep_movs case as well, but that one would first
>> need converting to switch(), which I agree is beyond the scope
>
> I agree that this is beyond the scope of this patch but it's not that
> big of a change and it can be done.
>
> But isn't having a default ASSERT_UNREACHABLE(); in both switch cases
> change the behavior of the function?
It shouldn't be the default case that gains this assertion,
but the HVMTRANS_need_retry one that is to be added.
>> of this change. In both cases a brief comment would seem
>> worthwhile adding, clarifying that the new return value can
>> result from hvm_copy_*_guest_linear() only. This might become
>> relevant in particular if, down the road, we invent more cases
>> where HVMTRANS_need_retry is produced.
>
> Is this comment aimed for the commit message or another place?
If you go the ASSERT_UNREACHABLE() route, then the comment(s)
should be code comments next to these assertions. They'd be
there to avoid people having to dig out the reason for why
they're there, to make it easy to decide whether it is safe to
drop them once some new producer of HVMTRANS_need_retry would
appear.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH for-4.13 v2] xen/arm32: setup: Give a xenheap page to the boot allocator
On Fri, 20 Sep 2019, Julien Grall wrote:
> After commit 6e3e771203 "xen/arm: setup: Relocate the Device-Tree later on
> in the boot", the boot allocator will not receive any xenheap page (i.e.
> mapped page) on Arm32.
>
> However, the boot allocator implicitely rely on having the first page
"implicitly relies"
I fixed the commit message and committed.
Reviewed-by: Stefano Stabellini
> already mapped and therefore result to break boot on Arm32.
>
> The easiest way for now is to give a xenheap page to the boot allocator.
> We may want to rethink the interface in the future.
>
> Fixes: 6e3e771203 ('xen/arm: setup: Relocate the Device-Tree later on in the
> boot')
> Signed-off-by: Julien Grall
> Reviewed-by: Jan Beulich
> ---
> Changes in v2:
> - Add Jan's reviewed-by
> - Use boot_mfn_start rather than boot_mfn_end when giving
> xenheap pages.
> ---
> xen/arch/arm/setup.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 581b262655..fca7e68cba 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -593,6 +593,7 @@ static void __init setup_mm(void)
> unsigned long heap_pages, xenheap_pages, domheap_pages;
> int i;
> const uint32_t ctr = READ_CP32(CTR);
> +mfn_t boot_mfn_start, boot_mfn_end;
>
> if ( !bootinfo.mem.nr_banks )
> panic("No memory bank\n");
> @@ -665,6 +666,11 @@ static void __init setup_mm(void)
>
> setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
>
> +/* We need a single mapped page for populating bootmem_region_list. */
> +boot_mfn_start = mfn_add(xenheap_mfn_end, -1);
> +boot_mfn_end = xenheap_mfn_end;
> +init_boot_pages(mfn_to_maddr(boot_mfn_start),
> mfn_to_maddr(boot_mfn_end));
> +
> /* Add non-xenheap memory */
> for ( i = 0; i < bootinfo.mem.nr_banks; i++ )
> {
> @@ -710,7 +716,7 @@ static void __init setup_mm(void)
>
> /* Add xenheap memory that was not already added to the boot allocator.
> */
> init_xenheap_pages(mfn_to_maddr(xenheap_mfn_start),
> - mfn_to_maddr(xenheap_mfn_end));
> + mfn_to_maddr(boot_mfn_start));
> }
> #else /* CONFIG_ARM_64 */
> static void __init setup_mm(void)
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early
Hi,
On 20/09/2019 16:16, Stefano Stabellini wrote:
On Fri, 20 Sep 2019, Julien Grall wrote:
On 20/09/2019 00:37, Stefano Stabellini wrote:
On Tue, 17 Sep 2019, Julien Grall wrote:
The current implementations of xen_{map, unmap}_table() expect
{map, unmap}_domain_page() to be usable. Those helpers are used to
map/unmap page tables while update Xen page-tables.
Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT update in
{set, clear}_fixmap()", setup_fixmap() will make use of the helpers
mentioned above. When booting Xen using GRUB, setup_fixmap() may be used
before map_domain_page() can be called. This will result to data abort:
(XEN) Data Abort Trap. Syndrome=0x5
(XEN) CPU0: Unexpected Trap: Data Abort
[...]
(XEN) Xen call trace:
(XEN)[<0025ab6c>] mm.c#xen_pt_update+0x2b4/0x59c (PC)
(XEN)[<0025ab20>] mm.c#xen_pt_update+0x268/0x59c (LR)
(XEN)[<0025ae70>] set_fixmap+0x1c/0x2c
(XEN)[<002a9c98>] copy_from_paddr+0x7c/0xdc
(XEN)[<002a4ae0>] has_xsm_magic+0x18/0x34
(XEN)[<002a5b5c>] bootfdt.c#early_scan_node+0x398/0x560
(XEN)[<002a5de0>] device_tree_for_each_node+0xbc/0x144
(XEN)[<002a5ed4>] boot_fdt_info+0x6c/0x260
(XEN)[<002ac0d0>] start_xen+0x108/0xc74
(XEN)[<0020044c>] arm64/head.o#paging+0x60/0x88
During early boot, the page tables are either statically allocated in
Xen binary or allocated via alloc_boot_pages().
For statically allocated page-tables, they will already be mapped as
part of Xen binary. So we can easily find the virtual address.
For dynamically allocated page-tables, we need to rely
map_domain_page() to be functionally working.
For arm32, the call will be usable much before page can be dynamically
allocated (see setup_pagetables()). For arm64, the call will be usable
after setup_xenheap_mappings().
In both cases, memory are given to the boot allocator afterwards. So we
can rely on map_domain_page() for mapping page tables allocated
dynamically.
The helpers xen_{map, unmap}_table() are now updated to take into
account the case where page-tables are part of Xen binary.
Fixes: 022387ee1a ('xen/arm: mm: Don't open-code Xen PT update in {set,
clear}_fixmap()')
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 20
1 file changed, 20 insertions(+)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index e1cdeaaf2f..da6303a8fd 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -950,11 +950,31 @@ static int create_xen_table(lpae_t *entry)
static lpae_t *xen_map_table(mfn_t mfn)
{
+/*
+ * We may require to map the page table before map_domain_page() is
+ * useable. The requirements here is it must be useable as soon as
+ * page-tables are allocated dynamically via alloc_boot_pages().
+ */
+if ( system_state == SYS_STATE_early_boot )
+{
+vaddr_t va = mfn_to_maddr(mfn) - phys_offset;
+
+if ( is_kernel(va) )
+return (lpae_t *)va;
Is it intended to continue if it is not a xen text page? Shouldn't we
BUG() or WARN?
Yes, I wrote the rationale in the commit message and a summary in a few lines
above. For convenience, I pasted the commit message again here:
The commit message explains what you are doing but I am still missing
something.
Why are we continuing if system_state == SYS_STATE_early_boot and
!is_kernel(va)?
The commit message explains that if system_state == SYS_STATE_early_boot
pagetable pages are static, right?
That's not correct. Below an excerpt of the commit message:
"During early boot, the page tables are either statically allocated in
Xen binary or allocated via alloc_boot_pages()."
An example of dynamic allocation happening when system_state ==
SYS_STATE_early_boot is in setup_xenheap_mappings(). alloc_boot_pages() will be
used to allocate intermediate page-tables as the runtime allocator is not yet ready.
Only after dynamic allocation are
possible it makes sense to use map_domain_page, and dynamic allocations
are possible roughly when system_state switched to SYS_STATE_boot.
That's not correct. alloc_boot_pages() is actually here to allow dynamic
allocation before the memory subsystem (and therefore the runtime allocator) is
initialized.
Half of the commit message actually explain when dynamic allocation can be used.
I am not entirely sure what is unclear in it so please suggest a different
commit message.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 25/47] xen/sched: add runstate counters to struct sched_unit
On 14.09.2019 10:52, Juergen Gross wrote: > @@ -368,7 +372,7 @@ static struct sched_unit *sched_alloc_unit(struct vcpu *v) > unit->vcpu_list = v; > unit->unit_id = v->vcpu_id; > unit->domain = d; > -v->sched_unit = unit; > +unit->runstate_cnt[v->runstate.state]++; > > for ( prev_unit = &d->sched_unit_list; *prev_unit; >prev_unit = &(*prev_unit)->next_in_list ) > @@ -384,6 +388,8 @@ static struct sched_unit *sched_alloc_unit(struct vcpu *v) > !zalloc_cpumask_var(&unit->cpu_soft_affinity) ) > goto fail; > > +v->sched_unit = unit; > + > return unit; > > fail: Is this movement of the assignment something which really belongs here, rather than in some earlier patch (perhaps the one actually introducing it)? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 5/6] xen/x86: add PHYSDEVOP_interrupt_control
On Fri, Sep 20, 2019 at 12:10:09PM +0200, Jan Beulich wrote: > On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote: > > Allow device model running in stubdomain to enable/disable INTx/MSI(-X), > > bypassing pciback. While pciback is still used to access config space > > from within stubdomain, it refuse to write to > > PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE/PCI_COMMAND_INTX_DISABLE > > in non-permissive mode. Which is the right thing to do for PV domain > > (the main use case for pciback), as PV domain should use XEN_PCI_OP_* > > commands for that. Unfortunately those commands are not good for > > stubdomain use, as they configure MSI in dom0's kernel too, which should > > not happen for HVM domain. > > Why the "for HVM domain" here? I.e. why would this be correct for > a PV domain? Besides my dislike for such a bypass (imo all of the > handling should go through pciback, or none of it) I continue to > wonder whether the problem can't be addressed by a pciback change. > And even if not, I'd still wonder whether the request shouldn't go > through pciback, to retain proper layering. Ultimately it may be > better to have even the map/unmap go through pciback (it's at > least an apparent violation of the original physdev-op model that > these two are XSM_DM_PRIV). Technically it should be possible to move this part to pciback, and in fact this is what I've considered in the first version of this series. But Roger points out on each version[1] of this series that pciback is meant to serve *PV* domains, where a PCI passthrough is a completely different different beast. In fact, I even consider that using pcifront in a Linux stubdomain as a proxy for qemu there may be a bad idea (one needs to be careful to avoid stubdomain kernel fighting with qemu about device state). Roger, what is the state of Xen internal vPCI? If handling PCI passthrough in Xen (or maybe standalone emulator), without qemu help is going to happen sooner than later (I guess not 4.13, but maybe 4.14?), then maybe this whole patch doesn't make sense as a temporary measure? Anyway, if you all agree that pciback should be the way to go, I can go that route too. In practice, it would be a flag (set by the toolstack?) allowing writes to appropriate config space registers directly (with appropriate checks, as in this patch). [1] https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00486.html -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 28/47] xen/sched: add code to sync scheduling of all vcpus of a sched unit
On 14.09.2019 10:52, Juergen Gross wrote:
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -55,6 +55,9 @@ boolean_param("sched_smt_power_savings",
> sched_smt_power_savings);
> int sched_ratelimit_us = SCHED_DEFAULT_RATELIMIT_US;
> integer_param("sched_ratelimit_us", sched_ratelimit_us);
>
> +/* Number of vcpus per struct sched_unit. */
> +static unsigned int __read_mostly sched_granularity = 1;
Didn't you indicate earlier that this would be a per-pool property?
Or was that just a longer term plan?
> +/*
> + * Rendezvous before taking a scheduling decision.
> + * Called with schedule lock held, so all accesses to the rendezvous counter
> + * can be normal ones (no atomic accesses needed).
> + * The counter is initialized to the number of cpus to rendezvous initially.
> + * Each cpu entering will decrement the counter. In case the counter becomes
> + * zero do_schedule() is called and the rendezvous counter for leaving
> + * context_switch() is set. All other members will wait until the counter is
> + * becoming zero, dropping the schedule lock in between.
> + */
This recurring lock/unlock is liable to cause a massive cache line
ping-pong, especially for socket or node scheduling. Instead of
just a cpu_relax() between the main unlock and re-lock, could there
perhaps be lock-less checks to determine whether there's any point
at all re-acquiring the lock?
> +static void schedule(void)
> +{
> +struct vcpu *vnext, *vprev = current;
> +struct sched_unit*prev = vprev->sched_unit, *next = NULL;
> +s_time_t now;
> +struct sched_resource *sd;
> +spinlock_t *lock;
> +int cpu = smp_processor_id();
> +
> +ASSERT_NOT_IN_ATOMIC();
> +
> +SCHED_STAT_CRANK(sched_run);
> +
> +sd = get_sched_res(cpu);
> +
> +lock = pcpu_schedule_lock_irq(cpu);
> +
> +if ( prev->rendezvous_in_cnt )
> +{
> +/*
> + * We have a race: sched_slave() should be called, so raise a softirq
> + * in order to re-enter schedule() later and call sched_slave() now.
> + */
> +pcpu_schedule_unlock_irq(lock, cpu);
> +
> +raise_softirq(SCHEDULE_SOFTIRQ);
> +return sched_slave();
> +}
> +
> +now = NOW();
> +
> +stop_timer(&sd->s_timer);
Is the order of these two relevant? A while ago there were a couple
of changes moving such NOW() invocations past anything that may take
non-negligible time, to make accounting as accurate as possible.
> --- a/xen/include/xen/softirq.h
> +++ b/xen/include/xen/softirq.h
> @@ -4,6 +4,7 @@
> /* Low-latency softirqs come first in the following list. */
> enum {
> TIMER_SOFTIRQ = 0,
> +SCHED_SLAVE_SOFTIRQ,
> SCHEDULE_SOFTIRQ,
> NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ,
> RCU_SOFTIRQ,
Seeing the comment, is the insertion you do as well as the pre-
existing placement of SCHEDULE_SOFTIRQ still appropriate with
the rendezvous-ing you introduce?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 00/47] xen: add core scheduling support
On 14.09.2019 10:52, Juergen Gross wrote: > This is achieved by switching the scheduler to no longer see vcpus as > the primary object to schedule, but "schedule units". Each schedule > unit consists of as many vcpus as each core has threads on the current > system. The vcpu->unit relation is fixed. There's another aspect here that, while perhaps obvious, I didn't realize so far: Iirc right now schedulers try to place vCPU-s on different cores, as long as there aren't more runnable vCPU-s than there are cores. This is to improve overall throughput, since vCPU-s on sibling hyperthreads would compete for execution resources. With a fixed relation this is going to be impossible. Otoh I can of course see how, once we have proper virtual topology, this allows better scheduling decisions inside the guest, in particular if - under the right circumstances - it is actually wanted to run two entities on sibling threads. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] tools/ocaml: Build fix following libxl API changes
The following libxl API became asynchronous and gained an additional
`ao_how' parameter:
libxl_domain_pause()
libxl_domain_unpause()
libxl_send_trigger()
Adapt the ocaml binding.
Build tested only.
Fixes: edaa631ddcee665cdfae1cf6bc7492c791e01ef4
Fixes: 95627b87c3159928458ee586e8c5c593bdd248d8
Signed-off-by: Anthony PERARD
---
Notes:
Currently, all libxl API that takes an `ao_how` have `?async:'a -> unit`
in the ocaml definition (and an extra unused value unit in the c stub
file), is that `unit` needed ?
I tried to add it, but then for stub_xl_send_trigger() I had to use
CAMLparam6, and that doesn't exist.
tools/ocaml/libs/xl/xenlight.ml.in | 6 +++---
tools/ocaml/libs/xl/xenlight.mli.in | 6 +++---
tools/ocaml/libs/xl/xenlight_stubs.c | 27 ++-
3 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in
b/tools/ocaml/libs/xl/xenlight.ml.in
index 80e620a9be66..954e56fc740b 100644
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -41,10 +41,10 @@ module Domain = struct
external reboot : ctx -> domid -> unit = "stub_libxl_domain_reboot"
external destroy : ctx -> domid -> ?async:'a -> unit -> unit =
"stub_libxl_domain_destroy"
external suspend : ctx -> domid -> Unix.file_descr -> ?async:'a -> unit
-> unit = "stub_libxl_domain_suspend"
- external pause : ctx -> domid -> unit = "stub_libxl_domain_pause"
- external unpause : ctx -> domid -> unit = "stub_libxl_domain_unpause"
+ external pause : ctx -> domid -> ?async:'a -> unit =
"stub_libxl_domain_pause"
+ external unpause : ctx -> domid -> ?async:'a -> unit =
"stub_libxl_domain_unpause"
- external send_trigger : ctx -> domid -> trigger -> int -> unit =
"stub_xl_send_trigger"
+ external send_trigger : ctx -> domid -> trigger -> int -> ?async:'a ->
unit = "stub_xl_send_trigger"
external send_sysrq : ctx -> domid -> char -> unit =
"stub_xl_send_sysrq"
end
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in
b/tools/ocaml/libs/xl/xenlight.mli.in
index b2c06b5eed76..c08304ae8b01 100644
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -43,10 +43,10 @@ module Domain : sig
external reboot : ctx -> domid -> unit = "stub_libxl_domain_reboot"
external destroy : ctx -> domid -> ?async:'a -> unit -> unit =
"stub_libxl_domain_destroy"
external suspend : ctx -> domid -> Unix.file_descr -> ?async:'a -> unit
-> unit = "stub_libxl_domain_suspend"
- external pause : ctx -> domid -> unit = "stub_libxl_domain_pause"
- external unpause : ctx -> domid -> unit = "stub_libxl_domain_unpause"
+ external pause : ctx -> domid -> ?async:'a -> unit =
"stub_libxl_domain_pause"
+ external unpause : ctx -> domid -> ?async:'a -> unit =
"stub_libxl_domain_unpause"
- external send_trigger : ctx -> domid -> trigger -> int -> unit =
"stub_xl_send_trigger"
+ external send_trigger : ctx -> domid -> trigger -> int -> ?async:'a ->
unit = "stub_xl_send_trigger"
external send_sysrq : ctx -> domid -> char -> unit =
"stub_xl_send_sysrq"
end
diff --git a/tools/ocaml/libs/xl/xenlight_stubs.c
b/tools/ocaml/libs/xl/xenlight_stubs.c
index 0140780a342e..37b046df6351 100644
--- a/tools/ocaml/libs/xl/xenlight_stubs.c
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c
@@ -622,32 +622,38 @@ value stub_libxl_domain_suspend(value ctx, value domid,
value fd, value async, v
CAMLreturn(Val_unit);
}
-value stub_libxl_domain_pause(value ctx, value domid)
+value stub_libxl_domain_pause(value ctx, value domid, value async)
{
- CAMLparam2(ctx, domid);
+ CAMLparam3(ctx, domid, async);
int ret;
uint32_t c_domid = Int_val(domid);
+ libxl_asyncop_how *ao_how = aohow_val(async);
caml_enter_blocking_section();
- ret = libxl_domain_pause(CTX, c_domid);
+ ret = libxl_domain_pause(CTX, c_domid, ao_how);
caml_leave_blocking_section();
+ free(ao_how);
+
if (ret != 0)
failwith_xl(ret, "domain_pause");
CAMLreturn(Val_unit);
}
-value stub_libxl_domain_unpause(value ctx, value domid)
+value stub_libxl_domain_unpause(value ctx, value domid, value async)
{
- CAMLparam2(ctx, domid);
+ CAMLparam3(ctx, domid, async);
int ret;
uint32_t c_domid = Int_val(domid);
+ libxl_asyncop_how *ao_how = aohow_val(async);
caml_enter_blocking_section();
- ret = libxl_domain_unpause(CTX, c_domid);
+ ret = libxl_domain_unpause(CTX, c_domid, ao_how);
caml_leave_blocking_section();
+ free(ao_how);
+
if (ret != 0)
failwith_xl(ret, "domain_unpause");
@@ -1031,20 +1037,23 @@ value stub_xl_domain_sched_params_set(value ctx, value
domid, value scinfo)
CAMLreturn(Val_unit);
}
-value stub_xl_send_trigger(value ctx,
[Xen-devel] [linux-4.9 test] 141476: regressions - FAIL
flight 141476 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141476/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 141392 REGR. vs. 141254 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail pass in 141392 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 11 examine-serial/bootloaderfail like 141277 test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail like 141277 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 141277 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 141277 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 141277 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 141277 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 141277 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfa
[Xen-devel] [xen-unstable-smoke test] 141513: regressions - trouble: blocked/fail
flight 141513 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141513/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 141253 build-amd64 6 xen-buildfail REGR. vs. 141253 build-armhf 6 xen-buildfail REGR. vs. 141253 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen a30910bfd71a64895f0d6ddbb301cf1b5ed6c2f4 baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Last test of basis 141253 2019-09-12 17:00:43 Z7 days Failing since141255 2019-09-12 21:01:22 Z7 days 52 attempts Testing same since 141508 2019-09-20 13:00:42 Z0 days2 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Chao Gao Christian Lindig Daniel De Graaf Ian Jackson Jan Beulich Juergen Gross Julien Grall Oleksandr Tyshchenko Paul Durrant Pawel Wieczorkiewicz Roger Pau Monné Stefano Stabellini Stefano Stabellini Volodymyr Babchuk Wei Liu Wei Liu jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1732 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools/ocaml: Build fix following libxl API changes
On Fri, Sep 20, 2019 at 05:19:02PM +0100, Anthony PERARD wrote: > The following libxl API became asynchronous and gained an additional > `ao_how' parameter: > libxl_domain_pause() > libxl_domain_unpause() > libxl_send_trigger() > > Adapt the ocaml binding. > > Build tested only. > > Fixes: edaa631ddcee665cdfae1cf6bc7492c791e01ef4 > Fixes: 95627b87c3159928458ee586e8c5c593bdd248d8 > Signed-off-by: Anthony PERARD > --- > > Notes: > Currently, all libxl API that takes an `ao_how` have `?async:'a -> unit` > in the ocaml definition (and an extra unused value unit in the c stub > file), is that `unit` needed ? > > I tried to add it, but then for stub_xl_send_trigger() I had to use > CAMLparam6, and that doesn't exist. I discovered CAMLxparam1 macro, but that's not better: File "xenlight.ml", line 1735, characters 25-84: Error: An external function with more than 5 arguments requires a second stub function for native-code compilation -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] tools/ocaml: Build fix following libxl API changes
Anthony PERARD writes ("Re: [PATCH] tools/ocaml: Build fix following libxl API
changes"):
> On Fri, Sep 20, 2019 at 05:19:02PM +0100, Anthony PERARD wrote:
> > The following libxl API became asynchronous and gained an additional
> > `ao_how' parameter:
> > libxl_domain_pause()
> > libxl_domain_unpause()
> > libxl_send_trigger()
> >
> > Adapt the ocaml binding.
> >
> > Build tested only.
> >
> > Fixes: edaa631ddcee665cdfae1cf6bc7492c791e01ef4
> > Fixes: 95627b87c3159928458ee586e8c5c593bdd248d8
> > Signed-off-by: Anthony PERARD
> > ---
> >
> > Notes:
> > Currently, all libxl API that takes an `ao_how` have `?async:'a -> unit`
> > in the ocaml definition (and an extra unused value unit in the c stub
> > file), is that `unit` needed ?
> >
> > I tried to add it, but then for stub_xl_send_trigger() I had to use
> > CAMLparam6, and that doesn't exist.
>
> I discovered CAMLxparam1 macro, but that's not better:
> File "xenlight.ml", line 1735, characters 25-84:
> Error: An external function with more than 5 arguments requires a second
> stub function
>for native-code compilation
In order to unbreak the build I have acked and pushed this patch right
away, but IMO a review from an ocaml maintainer is quite important
here.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.4 test] 141482: regressions - FAIL
flight 141482 linux-4.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141482/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 141448 REGR. vs. 139698 Tests which are failing intermittently (not blocking): test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail in 141448 pass in 141482 test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail pass in 141448 test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail pass in 141448 test-armhf-armhf-libvirt-raw 10 debian-di-install fail pass in 141448 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 141448 never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 141448 never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 141448 never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-arm64-arm64-examine 8 reboot fail never pass test-arm64-arm64-libvirt-xsm 7 xen-boot fail never pass test-arm64-arm64-xl 7 xen-boot fail never pass test-arm64-arm64-xl-seattle 7 xen-boot fail never pass test-arm64-arm64-xl-xsm 7 xen-boot fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 7 xen-boot fail never pass test-arm64-arm64-xl-credit2 7 xen-boot fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 7 xen-boot fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 wind
Re: [Xen-devel] [PATCH] tools/ocaml: Build fix following libxl API changes
On 20/09/2019 17:19, Anthony PERARD wrote: > The following libxl API became asynchronous and gained an additional > `ao_how' parameter: > libxl_domain_pause() > libxl_domain_unpause() > libxl_send_trigger() > > Adapt the ocaml binding. > > Build tested only. > > Fixes: edaa631ddcee665cdfae1cf6bc7492c791e01ef4 > Fixes: 95627b87c3159928458ee586e8c5c593bdd248d8 > Signed-off-by: Anthony PERARD This library is entirely unused, full of memory leaks, and has a number of areas needing extremely careful design due to the differing behaviours of the libxl and ocaml runtimes. Another option would be to drop the bindings entirely. > --- > > Notes: > Currently, all libxl API that takes an `ao_how` have `?async:'a -> unit` > in the ocaml definition (and an extra unused value unit in the c stub > file), is that `unit` needed ? > > I tried to add it, but then for stub_xl_send_trigger() I had to use > CAMLparam6, and that doesn't exist. In the Ocaml FFI, with more than 5 parameters, the entire set of parameters is spilled to memory as an array, so the C side of the function ends with a CAMLparam2 (list pointer and number of entries), and has extra marshalling to do. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 141521: regressions - trouble: blocked/fail
flight 141521 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141521/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 141253 build-amd64 6 xen-buildfail REGR. vs. 141253 build-armhf 6 xen-buildfail REGR. vs. 141253 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen ae84f55353475f569daddb9a81ac0a6bc7772c90 baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Last test of basis 141253 2019-09-12 17:00:43 Z8 days Failing since141255 2019-09-12 21:01:22 Z7 days 53 attempts Testing same since 141521 2019-09-20 17:08:20 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Chao Gao Christian Lindig Daniel De Graaf Ian Jackson Jan Beulich Juergen Gross Julien Grall Oleksandr Tyshchenko Paul Durrant Pawel Wieczorkiewicz Roger Pau Monné Stefano Stabellini Stefano Stabellini Volodymyr Babchuk Wei Liu Wei Liu jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1756 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke bisection] complete build-arm64-xsm
branch xen-unstable-smoke xenbranch xen-unstable-smoke job build-arm64-xsm testid xen-build Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: edaa631ddcee665cdfae1cf6bc7492c791e01ef4 Bug not present: d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/141535/ commit edaa631ddcee665cdfae1cf6bc7492c791e01ef4 Author: Anthony PERARD Date: Thu May 23 11:54:52 2019 +0100 libxl: Make libxl_domain_unpause async libxl_domain_unpause needs to make QMP calls, which are asynchronous, change the API to reflect that. Do the same with libxl_domain_pause async, even if it will keep completing synchronously. Also fix some coding style issue in those functions. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-arm64-xsm.xen-build --summary-out=tmp/141535.bisection-summary --basis-template=141253 --blessings=real,real-bisect xen-unstable-smoke build-arm64-xsm xen-build Searching for failure / basis pass: 141521 fail [host=laxton1] / 141498 [host=rochester1] 141494 [host=laxton0] 141489 [host=laxton0] 141485 [host=rochester0] 141480 [host=laxton0] 141474 [host=laxton0] 141470 ok. Failure / basis pass flights: 141521 / 141470 Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest cef9660618a880ced798375a0fd16a8ad80bd0f0 ae84f55353475f569daddb9a81ac0a6bc7772c90 Basis pass cef9660618a880ced798375a0fd16a8ad80bd0f0 88339ae94f4309888eae81a6cceac9577a319d7e Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen.git#cef9660618a880ced798375a0fd16a8ad80bd0f0-cef9660618a880ced798375a0fd16a8ad80bd0f0 git://xenbits.xen.org/xen.git#88339ae94f4309888eae81a6cceac9577a319d7e-ae84f55353475f569daddb9a81ac0a6bc7772c90 Loaded 1001 nodes in revision graph Searching for test results: 141513 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 a30910bfd71a64895f0d6ddbb301cf1b5ed6c2f4 141489 [host=laxton0] 141485 [host=rochester0] 141474 [host=laxton0] 141470 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 88339ae94f4309888eae81a6cceac9577a319d7e 141498 [host=rochester1] 141480 [host=laxton0] 141494 [host=laxton0] 141514 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 a30910bfd71a64895f0d6ddbb301cf1b5ed6c2f4 141508 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 a30910bfd71a64895f0d6ddbb301cf1b5ed6c2f4 141512 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 88339ae94f4309888eae81a6cceac9577a319d7e 141515 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 8efef84cf25a93a74499a809fa655e8ceedc6f86 141517 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 dbe92a588c429324fb2b7c02eb1e1cc7027ef8e3 141518 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 3bf9b8fde811c965b425d621d2651434a95cfe4a 141522 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 edaa631ddcee665cdfae1cf6bc7492c791e01ef4 141524 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 4750c9237bd49a2179d5bd28e7259df9c46de25a 141525 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6 141521 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 ae84f55353475f569daddb9a81ac0a6bc7772c90 141527 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 edaa631ddcee665cdfae1cf6bc7492c791e01ef4 141528 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 88339ae94f4309888eae81a6cceac9577a319d7e 141530 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 ae84f55353475f569daddb9a81ac0a6bc7772c90 141532 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6 141533 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 edaa631ddcee665cdfae1cf6bc7492c791e01ef4 141534 pass cef9660618a880ced798375a0fd16a8ad80bd0f0 d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6 141535 fail cef9660618a880ced798375a0fd16a8ad80bd0f0 edaa631ddcee665cdfae1cf6bc7492c791e01ef4 Searching for interesting versions Result found: flight 141470 (pass), for basis pass Result found: flight 141521 (fail), for basis failure Repro found: flight 141528 (pass), for basis pass Repro found: flight 141530 (fail), for basis failure 0 revisions at cef9660618a880ced798375a0fd16a8ad80bd0f0 d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6 No revisions left to test, checking graph state. Result found: flight 141525 (pass), for last pass Result found: flight 141527 (fail), for first failure Repro found: flight 141532 (pass), for last pass Repro found: flight 141533 (fail), for first failure Repr
[Xen-devel] [xen-unstable-smoke test] 141531: regressions - trouble: blocked/fail
flight 141531 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141531/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 141253 build-amd64 6 xen-buildfail REGR. vs. 141253 build-armhf 6 xen-buildfail REGR. vs. 141253 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a version targeted for testing: xen ae84f55353475f569daddb9a81ac0a6bc7772c90 baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Last test of basis 141253 2019-09-12 17:00:43 Z8 days Failing since141255 2019-09-12 21:01:22 Z7 days 54 attempts Testing same since 141521 2019-09-20 17:08:20 Z0 days2 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Chao Gao Christian Lindig Daniel De Graaf Ian Jackson Jan Beulich Juergen Gross Julien Grall Oleksandr Tyshchenko Paul Durrant Pawel Wieczorkiewicz Roger Pau Monné Stefano Stabellini Stefano Stabellini Volodymyr Babchuk Wei Liu Wei Liu jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1756 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Qemu-block] [PATCH] xen-block: treat XenbusStateUnknown the same as XenbusStateClosed
On 9/18/19 7:57 AM, Paul Durrant wrote:
> When a frontend gracefully disconnects from an offline backend, it will
> set its own state to XenbusStateClosed. The code in xen-block.c correctly
> deals with this and sets the backend into XenbusStateClosed. Unfortunately
> it is possible for toolstack to actually delete the frontend area
> before the state key has been read, leading to an apparent frontend state
> of XenbusStateUnknown. This prevents the backend state from transitioning
> to XenbusStateClosed and hence leaves it limbo.
>
Does the 0 come from a read into de-allocated memory?
--js
> This patch simply treats a frontend state of XenbusStateUnknown the same
> as XenbusStateClosed, which will unblock the backend in these circumstances.
>
> Reported-by: Mark Syms
> Signed-off-by: Paul Durrant
> ---
> Cc: Stefano Stabellini
> Cc: Anthony Perard
> Cc: Kevin Wolf
> Cc: Max Reitz
> ---
> hw/block/xen-block.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
> index f77343db60..879fc310a4 100644
> --- a/hw/block/xen-block.c
> +++ b/hw/block/xen-block.c
> @@ -313,6 +313,7 @@ static void xen_block_frontend_changed(XenDevice *xendev,
> break;
>
> case XenbusStateClosed:
> +case XenbusStateUnknown:
> xen_block_disconnect(xendev, &local_err);
> if (local_err) {
> error_propagate(errp, local_err);
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 141539: regressions - trouble: blocked/fail
flight 141539 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141539/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 141253 build-amd64 6 xen-buildfail REGR. vs. 141253 build-armhf 6 xen-buildfail REGR. vs. 141253 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen ae84f55353475f569daddb9a81ac0a6bc7772c90 baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Last test of basis 141253 2019-09-12 17:00:43 Z8 days Failing since141255 2019-09-12 21:01:22 Z8 days 55 attempts Testing same since 141521 2019-09-20 17:08:20 Z0 days3 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Chao Gao Christian Lindig Daniel De Graaf Ian Jackson Jan Beulich Juergen Gross Julien Grall Oleksandr Tyshchenko Paul Durrant Pawel Wieczorkiewicz Roger Pau Monné Stefano Stabellini Stefano Stabellini Volodymyr Babchuk Wei Liu Wei Liu jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1756 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 141484: regressions - FAIL
flight 141484 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/141484/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-examine 8 reboot fail REGR. vs. 133580 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-boot fail REGR. vs. 133580 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 133580 test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 133580 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 133580 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 133580 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 133580 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail
[Xen-devel] Crash with nested HVM and Linux v5.1+
With nestedhvm=1, the L2 HVM guest is either hanging (Xen 4.8) or crashing (Xen 4.12.1) the L1 Xen hypervisor with recent versions of Linux. We isolated the commit to: commit 093ae8f9a86a974c920b613860f1f7fd5bbd70ab Author: Borislav Petkov Date: Thu Apr 12 13:11:36 2018 +0200 x86/TSC: Use RDTSCP Currently, the kernel uses [LM]FENCE; RDTSC in the timekeeping code, to guarantee monotonicity of time where the *FENCE is selected based on vendor. Replace that sequence with RDTSCP which is faster or on-par and gives the same guarantees. A microbenchmark on Intel shows that the change is on-par. On AMD, the change is either on-par with the current LFENCE-prefixed RDTSC or slightly better with RDTSCP. The comparison is done with the LFENCE-prefixed RDTSC (and not with the MFENCE-prefixed one, as one would normally expect) because all modern AMD families make LFENCE serializing and thus avoid the heavy MFENCE by effectively enabling X86_FEATURE_LFENCE_RDTSC. I could not find RDTSCP instruction being used by Linux before the given commit, which is present in Linux v5.1 and newer. As expected, masking off the RDTSCP cpuid flag in leaf 0x8001 prevents a cooperative guest from using that instruction and therefore prevents the crash. --Sarah ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [libvirt test] 141493: regressions - FAIL
flight 141493 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/141493/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs. 141415 test-armhf-armhf-libvirt-raw 18 leak-check/check fail REGR. vs. 141415 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 141415 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 141415 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass version targeted for testing: libvirt d72ed16ba73279e3f5779bbf1ca48ead3e97d3f9 baseline version: libvirt 522b3d2b24d0f7ac78dad442c990d4e34db0eaf2 Last test of basis 141415 2019-09-18 05:36:57 Z2 days Failing since141456 2019-09-19 04:19:21 Z1 days2 attempts Testing same since 141493 2019-09-20 04:18:41 Z0 days1 attempts People who touched revisions under test: Daniel P. Berrangé Ján Tomko Michal Privoznik Michal Prívozník Nikolay Shirokovskiy Peter Krempa Shi Lei Xu Yandong jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be
[Xen-devel] [xen-unstable-smoke test] 141546: regressions - trouble: blocked/fail
flight 141546 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141546/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 141253 build-amd64 6 xen-buildfail REGR. vs. 141253 build-armhf 6 xen-buildfail REGR. vs. 141253 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a version targeted for testing: xen ae84f55353475f569daddb9a81ac0a6bc7772c90 baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Last test of basis 141253 2019-09-12 17:00:43 Z8 days Failing since141255 2019-09-12 21:01:22 Z8 days 56 attempts Testing same since 141521 2019-09-20 17:08:20 Z0 days4 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Chao Gao Christian Lindig Daniel De Graaf Ian Jackson Jan Beulich Juergen Gross Julien Grall Oleksandr Tyshchenko Paul Durrant Pawel Wieczorkiewicz Roger Pau Monné Stefano Stabellini Stefano Stabellini Volodymyr Babchuk Wei Liu Wei Liu jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1756 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.19 test] 141490: regressions - FAIL
flight 141490 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/141490/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 129313 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 Tests which did not succeed, but are not blocking: 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-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 129313 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail 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-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: linuxdbc29aff8d04f134553326a0c533a442a1774041 baseline version: linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d Last test of basis 129313 2018-11-02 05:39:08 Z 322 days Failing since129412 2018-11-04 14:10:15 Z 320 days 239 attempts Testing same since 141490 2019-09-20 01:10:34 Z0 days1 attempts 2571 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf
[Xen-devel] [xen-unstable-smoke test] 141554: regressions - trouble: blocked/fail
flight 141554 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141554/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 141253 build-amd64 6 xen-buildfail REGR. vs. 141253 build-armhf 6 xen-buildfail REGR. vs. 141253 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: xen ae84f55353475f569daddb9a81ac0a6bc7772c90 baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Last test of basis 141253 2019-09-12 17:00:43 Z8 days Failing since141255 2019-09-12 21:01:22 Z8 days 57 attempts Testing same since 141521 2019-09-20 17:08:20 Z0 days5 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Chao Gao Christian Lindig Daniel De Graaf Ian Jackson Jan Beulich Juergen Gross Julien Grall Oleksandr Tyshchenko Paul Durrant Pawel Wieczorkiewicz Roger Pau Monné Stefano Stabellini Stefano Stabellini Volodymyr Babchuk Wei Liu Wei Liu jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1756 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [freebsd-master test] 141501: all pass - PUSHED
flight 141501 freebsd-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/141501/ Perfect :-) All tests in this flight passed as required version targeted for testing: freebsd 14aef6dfca96006e52b8fb920bde7c612ba58b79 baseline version: freebsd 2fa3479cfadb0bb3fe694dbfd29f2350eb2570df Last test of basis 141420 2019-09-18 09:19:54 Z2 days Testing same since 141501 2019-09-20 09:19:51 Z0 days1 attempts People who touched revisions under test: br kib jobs: build-amd64-freebsd-againpass build-amd64-freebsd pass build-amd64-xen-freebsd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/freebsd.git 2fa3479cfad..14aef6dfca9 14aef6dfca96006e52b8fb920bde7c612ba58b79 -> tested/master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable test] 141495: tolerable FAIL
flight 141495 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/141495/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt 19 leak-check/check fail pass in 141459 Tests which did not succeed, but are not blocking: test-arm64-arm64-examine 11 examine-serial/bootloader fail in 141459 like 141376 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 141459 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 141459 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 141459 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 141459 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 141459 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 141459 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 141459 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 141459 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 141459 test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 13 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b
[Xen-devel] [xen-unstable-smoke test] 141563: regressions - trouble: blocked/fail
flight 141563 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/141563/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-buildfail REGR. vs. 141253 build-amd64 6 xen-buildfail REGR. vs. 141253 build-armhf 6 xen-buildfail REGR. vs. 141253 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: xen ae84f55353475f569daddb9a81ac0a6bc7772c90 baseline version: xen 1014f47c7a808e025b8920ab80bfe73a2888b3e5 Last test of basis 141253 2019-09-12 17:00:43 Z8 days Failing since141255 2019-09-12 21:01:22 Z8 days 58 attempts Testing same since 141521 2019-09-20 17:08:20 Z0 days6 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Chao Gao Christian Lindig Daniel De Graaf Ian Jackson Jan Beulich Juergen Gross Julien Grall Oleksandr Tyshchenko Paul Durrant Pawel Wieczorkiewicz Roger Pau Monné Stefano Stabellini Stefano Stabellini Volodymyr Babchuk Wei Liu Wei Liu jobs: build-arm64-xsm fail build-amd64 fail build-armhf fail build-amd64-libvirt blocked test-armhf-armhf-xl blocked test-arm64-arm64-xl-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1756 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke bisection] complete build-amd64
branch xen-unstable-smoke xenbranch xen-unstable-smoke job build-amd64 testid xen-build Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: edaa631ddcee665cdfae1cf6bc7492c791e01ef4 Bug not present: d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/141560/ commit edaa631ddcee665cdfae1cf6bc7492c791e01ef4 Author: Anthony PERARD Date: Thu May 23 11:54:52 2019 +0100 libxl: Make libxl_domain_unpause async libxl_domain_unpause needs to make QMP calls, which are asynchronous, change the API to reflect that. Do the same with libxl_domain_pause async, even if it will keep completing synchronously. Also fix some coding style issue in those functions. Signed-off-by: Anthony PERARD Acked-by: Ian Jackson For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-amd64.xen-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-amd64.xen-build --summary-out=tmp/141571.bisection-summary --basis-template=141253 --blessings=real,real-bisect xen-unstable-smoke build-amd64 xen-build Searching for failure / basis pass: 141563 fail [host=godello0] / 141498 [host=godello1] 141494 ok. Failure / basis pass flights: 141563 / 141494 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 ae84f55353475f569daddb9a81ac0a6bc7772c90 Basis pass d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 ce44fd015e55d0ecc47c160fb5ce69070aa4991b Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#cef9660618a880ced798375a0fd16a8ad80bd0f0-cef9660618a880ced798375a0fd16a8ad80bd0f0 git://xenbits.xen.org/xen.git#ce44fd015e55d0ecc47c160fb5ce69070aa4991b-ae84f55353475f569daddb9a81ac0a6bc7772c90 Loaded 1001 nodes in revision graph Searching for test results: 141513 [host=godello1] 141489 pass d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 ce44fd015e55d0ecc47c160fb5ce69070aa4991b 141498 [host=godello1] 141494 pass d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 ce44fd015e55d0ecc47c160fb5ce69070aa4991b 141508 fail d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 a30910bfd71a64895f0d6ddbb301cf1b5ed6c2f4 141545 fail d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 edaa631ddcee665cdfae1cf6bc7492c791e01ef4 141565 [host=baroque0] 141521 [host=huxelrebe0] 141549 pass d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 4750c9237bd49a2179d5bd28e7259df9c46de25a 141551 pass d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6 141546 fail d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 ae84f55353475f569daddb9a81ac0a6bc7772c90 141552 fail d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 edaa631ddcee665cdfae1cf6bc7492c791e01ef4 141531 fail d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 ae84f55353475f569daddb9a81ac0a6bc7772c90 141536 [host=huxelrebe0] 141568 [host=baroque0] 141537 pass d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 ce44fd015e55d0ecc47c160fb5ce69070aa4991b 141540 fail d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 ae84f55353475f569daddb9a81ac0a6bc7772c90 141541 fail d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 ffc664dcb09654c9d34df68f3faf4d0b00642140 141539 fail d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 ae84f55353475f569daddb9a81ac0a6bc7772c90 141553 pass d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 d6c7cd918adcfdc8ae41cf89e6a47ef4e4d3c1f6 141542 pass d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0fd16a8ad80bd0f0 1d1800ed347de5da7d45523758e33561d0b3c72f 141543 fail d0d8ad39ecb51cd7497cd524484fe09f50876798 cef9660618a880ced798375a0f
