Re: [Xen-devel] [PATCH] xen: Remove unnecessary BUG_ON from __unbind_from_irq()
On Thu, Jun 21, 2018 at 01:29:44PM -0400, Boris Ostrovsky wrote:
> Commit 910f8befdf5b ("xen/pirq: fix error path cleanup when binding
> MSIs") fixed a couple of errors in error cleanup path of
> xen_bind_pirq_msi_to_irq(). This cleanup allowed a call to
> __unbind_from_irq() with an unbound irq, which would result in
> triggering the BUG_ON there.
>
> Since there is really no reason for the BUG_ON (xen_free_irq() can
> operate on unbound irqs) we can remove it.
>
> Reported-by: Ben Hutchings
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Roger Pau Monné
Thanks, I had this on my queue of TODOs.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] build: sync Kconfig with Linux v4.17
>>> On 22.06.18 at 00:24, wrote: >> >>> Working patch by patch isn't feasible because of the renames. >> >> >> >> I don't understand - how does path/file naming conflict with working >> >> patch by patch? Surely a relatively simple sed command could be used >> >> to change the paths in each patch according to our tree layout. That's >> >> basically what I'm doing with the MWAIT idle driver; granted, that's just >> >> a single file. >> > >> > Its 106 commits between the last time I got this in sync. We also don’t >> > have >> > kbuild and we have a little shim file to map things to our build system so >> > for each patch I would have to implement some of those regressions. >> >> Well, I still don't understand: You had to make those 106 commits apply >> to your tree as well in order to have create the patch you've submitted. >> Whatever you did (even if you created a giant patch first and massaged >> that one), the same could have been done for the individual commits. If >> this indeed takes more than a simple sed invocation, perhaps it would be >> worth adding a little script to our repo doing just that? > > So I didn't take those 106 commits individually as it was indicated that > would have been NACKed. Interesting. Were there any reasons indicated why that would be? > I didn't even use git proper, I ultimately checked > out the tag in my linux.git and used cp to copy the files over that I > mentioned in the commit message. Then I removed the files that went away > in Linux. I then attempted to build it and fixed up paths and other > snippets until it all worked. Its a manual process in its very nature. > > Originally when I proposed bringing in Kconfig I had used a script > that maintained things in the same paths as Linux and indeed allowed us > to just pull in patches from Linux. I believe the original RFC for > adding Kconfig started with Linux v4.1 or v4.2 and I had used that > script to update the final version to v4.3. This was ultimately not used > because the Xen-specific changes we make (e.g. paths changed, removal of > tests, use of Config.mk) that ultimately this a manual process. > > Ultimately are you looking for v2 to be which of the following: > - a series of 106 patches where each one is editted with the necessary > changes to make it work standalone (e.g. paths fixed, removal of > tests) This is what I personally would prefer. But seeing that you say others objected to this approach already, I'm not sure what to suggest. > - the current patch with details about the process documented in > README.source (which is a Xen specific file) and an expanded commit > message This would be a minimal requirement of mine. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-xl-xsm
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-xsm testid xen-boot Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git 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: 243435bf67e8159495194f623b9e4d8c90140384 Bug not present: 146dfe9277c2b4a8c399b229e00d819065e3167b Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/124587/ commit 243435bf67e8159495194f623b9e4d8c90140384 Author: Andrew Cooper Date: Thu Jun 7 17:00:37 2018 +0100 x86/spec-ctrl: Mitigations for LazyFPU Intel Core processors since at least Nehalem speculate past #NM, which is the mechanism by which lazy FPU context switching is implemented. On affected processors, Xen must use fully eager FPU context switching to prevent guests from being able to read FPU state (SSE/AVX/etc) from previously scheduled vcpus. This is part of XSA-267 / CVE-2018-3665 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-xl-xsm.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/xen-unstable/test-amd64-amd64-xl-xsm.xen-boot --summary-out=tmp/124587.bisection-summary --basis-template=124090 --blessings=real,real-bisect xen-unstable test-amd64-amd64-xl-xsm xen-boot Searching for failure / basis pass: 124472 fail [host=albana0] / 124299 [host=joubertin0] 124225 [host=elbling1] 124191 [host=debina0] 124170 [host=italia0] 124140 [host=godello0] 124090 [host=chardonnay0] 124057 [host=godello1] 124038 [host=huxelrebe1] 123994 [host=elbling0] 123932 [host=pinot0] 123874 [host=albana1] 123670 ok. Failure / basis pass flights: 124472 / 123670 (tree with no url: minios) (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git 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 cda6fd4d9382205bb792255cd56a91062d404bc0 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 988d66cb78c35c620c2a0eb01bac842e4e99bf0e Basis pass 57a3ca7835962109d94533465a75e8c716b26845 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 06f542f8f2e446c01bd0edab51e9450af7f6e05b Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#57a3ca7835962109d94533465a75e8c716b26845-cda6fd4d9382205bb792255cd56a91062d404bc0 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60 git://xenbits.xen.org/qemu-xen.git#43139135a8938de44f66333831d3a8655d07663a-43139135a8938de44f66333831d3a8655d07663a git://xenbits.xen.org/xen.git#06f542f8f2e446c01bd0edab51e9450af7f6e05b-988d66cb78c35c620c2a0eb01bac842e4e99bf0e Loaded 2001 nodes in revision graph Searching for test results: 123442 [host=joubertin1] 123569 [host=italia1] 123670 pass 57a3ca7835962109d94533465a75e8c716b26845 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 06f542f8f2e446c01bd0edab51e9450af7f6e05b 123932 [host=pinot0] 123874 [host=albana1] 123994 [host=elbling0] 124038 [host=huxelrebe1] 124057 [host=godello1] 124090 [host=chardonnay0] 124140 [host=godello0] 124170 [host=italia0] 124191 [host=debina0] 124299 [host=joubertin0] 124225 [host=elbling1] 124372 fail irrelevant 124416 fail irrelevant 124522 pass 1dd9566d954230d5dccb48d070dc412bc9358ca8 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 3960f3a52346348e6b0306f65d19375612bd35b9 124472 fail cda6fd4d9382205bb792255cd56a91062d404bc0 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 988d66cb78c35c620c2a0eb01bac842e4e99bf0e 124486 pass 57a3ca7835962109d94533465a75e8c716b26845 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 43139135a8938de44f66333831d3a8655d07663a 06f542f8f2e446c01bd0edab51e9450af7f6e05b 124516 fail irrelevant 1
Re: [Xen-devel] [PATCH] x86/EFI: further correct FPU state handling around runtime calls
>>> On 22.06.18 at 04:18, wrote:
> On 21/06/18 19:53, Jan Beulich wrote:
>> We must not leave a vCPU with CR0.TS clear when it is not in fully eager
>> mode and has not touched non-lazy state. Instead of adding a 3rd
>> invocation of stts() to vcpu_restore_fpu_eager(), consolidate all of
>> them into a single one done at the end of the function.
>>
>> The new function parameter is not really well named, but
>> "need_stts_if_not_fully_eager" seemed excessive to me. Suggestions
>> welcome.
>
> I think "maybe_stts" is reasonable here. At least it is accurate.
I had considered this name, and discarded it as specifically not
accurate: The call site in efi_rs_leave() absolutely wants the stts()
in not-fully-eager mode.
> OTOH, as we're changing all callsites, can we please rename the function
> to vcpu_restore_fpu_nonlazy() to match the rest of the terminology, and
> avoid this function looking like it restores all state.
Indeed, I could (and hence should) do this.
>> --- a/xen/arch/x86/i387.c
>> +++ b/xen/arch/x86/i387.c
>> @@ -206,11 +206,11 @@ static inline void fpu_fxsave(struct vcp
>> /* VCPU FPU Functions*/
>> /***/
>> /* Restore FPU state whenever VCPU is schduled in. */
>> -void vcpu_restore_fpu_eager(struct vcpu *v)
>> +void vcpu_restore_fpu_eager(struct vcpu *v, bool need_stts)
>> {
>> /* Restore nonlazy extended state (i.e. parts not tracked by CR0.TS).
> */
>> if ( !v->arch.fully_eager_fpu && !v->arch.nonlazy_xstate_used )
>> -return;
>> +goto maybe_stts;
>
> This surely needs to be is_pv_vcpu(v) && (v->arch.pv_vcpu.ctrlreg[0] &
> X86_CR0_TS); ?
>
> Otherwise, this patch reintroduces the path which unconditionally uses
> stts() around an EFI RS call.
We want an uncondtional stts() here unless in fully eager mode. That's the
crux with the parameter name: In fully eager mode, we clearly do not want
stts(), but otherwise and without doing anything in the function here, this
specific call path needs it. The other two paths don't:
- __context_switch() assumes CR0.TS is still set from the most recent
vcpu_save_fpu() (i.e. it is simply an optimization to avoid the stts()),
- hvmemul_put_fpu() invokes the function only for fully-eager vCPU-s.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] build: sync Kconfig with Linux v4.17
Hi, On 06/22/2018 08:42 AM, Jan Beulich wrote: On 22.06.18 at 00:24, wrote: Working patch by patch isn't feasible because of the renames. I don't understand - how does path/file naming conflict with working patch by patch? Surely a relatively simple sed command could be used to change the paths in each patch according to our tree layout. That's basically what I'm doing with the MWAIT idle driver; granted, that's just a single file. Its 106 commits between the last time I got this in sync. We also don’t have kbuild and we have a little shim file to map things to our build system so for each patch I would have to implement some of those regressions. Well, I still don't understand: You had to make those 106 commits apply to your tree as well in order to have create the patch you've submitted. Whatever you did (even if you created a giant patch first and massaged that one), the same could have been done for the individual commits. If this indeed takes more than a simple sed invocation, perhaps it would be worth adding a little script to our repo doing just that? So I didn't take those 106 commits individually as it was indicated that would have been NACKed. Interesting. Were there any reasons indicated why that would be? I could see few reasons to be grumpy with such a series in my inbox. Sending a series with 106 is just insane, more that probably no-one is going to look at patches one by one (they are imported from Linux). This is very similar to when a file is imported or update files from Linux (e.g usban, SMMU). We don't backport one by one the commit. Instead we batch in a single commit. So why does it have to be different here? I didn't even use git proper, I ultimately checked out the tag in my linux.git and used cp to copy the files over that I mentioned in the commit message. Then I removed the files that went away in Linux. I then attempted to build it and fixed up paths and other snippets until it all worked. Its a manual process in its very nature. Originally when I proposed bringing in Kconfig I had used a script that maintained things in the same paths as Linux and indeed allowed us to just pull in patches from Linux. I believe the original RFC for adding Kconfig started with Linux v4.1 or v4.2 and I had used that script to update the final version to v4.3. This was ultimately not used because the Xen-specific changes we make (e.g. paths changed, removal of tests, use of Config.mk) that ultimately this a manual process. Ultimately are you looking for v2 to be which of the following: - a series of 106 patches where each one is editted with the necessary changes to make it work standalone (e.g. paths fixed, removal of tests) This is what I personally would prefer. But seeing that you say others objected to this approach already, I'm not sure what to suggest. - the current patch with details about the process documented in README.source (which is a Xen specific file) and an expanded commit message I am not sure what would the README.source would give you here? Will it give a mapping with Linux commit for copyright reasons? Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] build: sync Kconfig with Linux v4.17
>>> On 22.06.18 at 10:11, wrote: > On 06/22/2018 08:42 AM, Jan Beulich wrote: > On 22.06.18 at 00:24, wrote: >>> Working patch by patch isn't feasible because of the renames. >> >> I don't understand - how does path/file naming conflict with working >> patch by patch? Surely a relatively simple sed command could be used >> to change the paths in each patch according to our tree layout. That's >> basically what I'm doing with the MWAIT idle driver; granted, that's just >> a single file. > > Its 106 commits between the last time I got this in sync. We also don’t > have > kbuild and we have a little shim file to map things to our build system so > for each patch I would have to implement some of those regressions. Well, I still don't understand: You had to make those 106 commits apply to your tree as well in order to have create the patch you've submitted. Whatever you did (even if you created a giant patch first and massaged that one), the same could have been done for the individual commits. If this indeed takes more than a simple sed invocation, perhaps it would be worth adding a little script to our repo doing just that? >>> >>> So I didn't take those 106 commits individually as it was indicated that >>> would have been NACKed. >> >> Interesting. Were there any reasons indicated why that would be? > > I could see few reasons to be grumpy with such a series in my inbox. > Sending a series with 106 is just insane, more that probably no-one is > going to look at patches one by one (they are imported from Linux). I can see the spam effect of such a patch bomb, sure. > This is very similar to when a file is imported or update files from > Linux (e.g usban, SMMU). We don't backport one by one the commit. > Instead we batch in a single commit. > > So why does it have to be different here? Initial importing is one thing: You either want it, or you don't. Subsequent updating is another, as explained in the original reply already. Do we _need_ any of this (bug fixes, new features)? Or is this _just_ to keep things somewhat in sync? After all, another option after the initial import is also to solely pull in changes we actually care about. And obviously there is a myriad of options somewhere in the middle between the two extremes. >>> I didn't even use git proper, I ultimately checked >>> out the tag in my linux.git and used cp to copy the files over that I >>> mentioned in the commit message. Then I removed the files that went away >>> in Linux. I then attempted to build it and fixed up paths and other >>> snippets until it all worked. Its a manual process in its very nature. >>> >>> Originally when I proposed bringing in Kconfig I had used a script >>> that maintained things in the same paths as Linux and indeed allowed us >>> to just pull in patches from Linux. I believe the original RFC for >>> adding Kconfig started with Linux v4.1 or v4.2 and I had used that >>> script to update the final version to v4.3. This was ultimately not used >>> because the Xen-specific changes we make (e.g. paths changed, removal of >>> tests, use of Config.mk) that ultimately this a manual process. >>> >>> Ultimately are you looking for v2 to be which of the following: >>> - a series of 106 patches where each one is editted with the necessary >>>changes to make it work standalone (e.g. paths fixed, removal of >>>tests) >> >> This is what I personally would prefer. But seeing that you say others >> objected to this approach already, I'm not sure what to suggest. >> >>> - the current patch with details about the process documented in >>>README.source (which is a Xen specific file) and an expanded commit >>>message > > I am not sure what would the README.source would give you here? Will it > give a mapping with Linux commit for copyright reasons? Doug said "details about the process documented", which I consider helpful for future sync-ing steps (which may end up be done by others than Doug). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Ping: [PATCH 2/2] x86/HVM: attempts to emulate FPU insns need to set fpu_initialised
>>> On 15.06.18 at 10:58, wrote:
> My original way of thinking here was that this would be set anyway at
> the point state gets reloaded after the adjustments hvmemul_put_fpu()
> does, but the flag should already be set before that - after all the
> guest may never again touch the FPU before e.g. getting migrated/saved.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2053,6 +2053,7 @@ static int hvmemul_get_fpu(
> * masking of all exceptions by FNSTENV.)
> */
> save_fpu_enable();
> +curr->fpu_initialised = true;
> curr->fpu_dirtied = true;
> if ( (fpu_ctxt->fcw & 0x3f) != 0x3f )
> {
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.14 test] 124508: regressions - FAIL
flight 124508 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/124508/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 6 xen-install fail REGR. vs. 124389 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 5 host-ping-check-native fail in 124456 pass in 124508 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat fail pass in 124456 Tests which did not succeed, but are not blocking: 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-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-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 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-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-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 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-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-i386-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-libvirt-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 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-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 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-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail 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-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-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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-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-i386-xl-qemut-ws16-amd64 17 guest-stop fail 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-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: linux33445c07cd45541410fb4cabd08b10827764c07f baseline version: linuxcda6fd4d9382205bb792255cd56a91062d404bc0 Last test of basis 124389 2018-06-19 04:33:40 Z3 days Testing same since 124456 2018-06-20 19:09:25 Z1 days
[Xen-devel] [PATCH RFC] x86/xsave: prefer eager clearing of state over eager restoring
Other than FXRSTOR, XRSTOR allows for setting components to their
initial state. Utilize this to clear register state immediately after
having saved a vCPU's state (which we don't defer past
__context_switch()), considering that
- this supposedly reduces power consumption,
- this might even free up physical registers,
- we don't normally save/restore FPU state for a vCPU on every context
switch (in some initial measurements I've observed an approximate
50:50 relation between the two on a not overly heavily loaded system;
it's clear anyway that this is heavily dependent on what exactly a
vCPU is used for).
Signed-off-by: Jan Beulich
---
RFC since the full performance effect is still not very clear.
--- a/xen/arch/x86/i387.c
+++ b/xen/arch/x86/i387.c
@@ -33,6 +33,7 @@ static inline void fpu_xrstor(struct vcp
ok = set_xcr0(v->arch.xcr0_accum | XSTATE_FP_SSE);
ASSERT(ok);
xrstor(v, mask);
+v->arch.xstate_dirty = mask;
ok = set_xcr0(v->arch.xcr0 ?: XSTATE_FP_SSE);
ASSERT(ok);
}
@@ -148,6 +149,9 @@ static inline void fpu_xsave(struct vcpu
ok = set_xcr0(v->arch.xcr0_accum | XSTATE_FP_SSE);
ASSERT(ok);
xsave(v, mask);
+xstate_load_init(v->arch.xstate_dirty &
+ v->arch.xsave_area->xsave_hdr.xstate_bv);
+v->arch.xstate_dirty = 0;
ok = set_xcr0(v->arch.xcr0 ?: XSTATE_FP_SSE);
ASSERT(ok);
}
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -616,7 +616,7 @@ void __init init_speculation_mitigations
/* Check whether Eager FPU should be enabled by default. */
if ( opt_eager_fpu == -1 )
-opt_eager_fpu = should_use_eager_fpu();
+opt_eager_fpu = !cpu_has_xsave && should_use_eager_fpu();
/* (Re)init BSP state now that default_spec_ctrl_flags has been
calculated. */
init_shadow_spec_ctrl_state();
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -734,6 +734,7 @@ int handle_xsetbv(u32 index, u64 new_bv)
cr0 &= ~X86_CR0_TS;
}
xrstor(curr, mask);
+curr->arch.xstate_dirty |= mask;
if ( cr0 & X86_CR0_TS )
write_cr0(cr0);
}
@@ -774,12 +775,19 @@ uint64_t read_bndcfgu(void)
return xstate->xsave_hdr.xstate_bv & X86_XCR0_BNDCSR ? bndcsr->bndcfgu : 0;
}
+void xstate_load_init(uint64_t mask)
+{
+struct vcpu *v = idle_vcpu[smp_processor_id()];
+struct xsave_struct *xstate = v->arch.xsave_area;
+
+memset(&xstate->xsave_hdr, 0, sizeof(xstate->xsave_hdr));
+xrstor(v, mask);
+}
+
void xstate_set_init(uint64_t mask)
{
unsigned long cr0 = read_cr0();
unsigned long xcr0 = this_cpu(xcr0);
-struct vcpu *v = idle_vcpu[smp_processor_id()];
-struct xsave_struct *xstate = v->arch.xsave_area;
if ( ~xfeature_mask & mask )
{
@@ -792,8 +800,7 @@ void xstate_set_init(uint64_t mask)
clts();
-memset(&xstate->xsave_hdr, 0, sizeof(xstate->xsave_hdr));
-xrstor(v, mask);
+xstate_load_init(mask);
if ( cr0 & X86_CR0_TS )
write_cr0(cr0);
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -559,6 +559,11 @@ struct arch_vcpu
* it explicitly enables it via xcr0.
*/
uint64_t xcr0_accum;
+/*
+ * Accumulated set of components which may currently be dirty, and hence
+ * should be cleared immediately after saving state.
+ */
+uint64_t xstate_dirty;
/* This variable determines whether nonlazy extended state has been used,
* and thus should be saved/restored. */
bool_t nonlazy_xstate_used;
--- a/xen/include/asm-x86/xstate.h
+++ b/xen/include/asm-x86/xstate.h
@@ -95,6 +95,7 @@ uint64_t get_msr_xss(void);
uint64_t read_bndcfgu(void);
void xsave(struct vcpu *v, uint64_t mask);
void xrstor(struct vcpu *v, uint64_t mask);
+void xstate_load_init(uint64_t mask);
void xstate_set_init(uint64_t mask);
bool xsave_enabled(const struct vcpu *v);
int __must_check validate_xstate(u64 xcr0, u64 xcr0_accum,
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 07/13] xen/arm: Simplify alternative patching of non-writable region
On Tue, Jun 12, 2018 at 11:06:16PM +0100, Julien Grall wrote:
> Hi Konrad,
>
> On 12/06/2018 22:17, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 12, 2018 at 12:36:37PM +0100, Julien Grall wrote:
> > > During the MMU setup process, Xen will set SCTLR_EL2.WNX
> > > (Write-Non-eXecutable) bit. Because of that, the alternative code need
> > > to re-mapped the region in a difference place in order to modify the
> > > text section.
> > >
> > > At the moment, the function patching the code is only aware of the
> > > re-mapped region. This requires the caller to mess with Xen internal in
> > > order to have function such as is_active_kernel_text() working.
> > >
> > > All the interactions with Xen internal can be removed by specifying the
> > > offset between the region patch and the writable region for updating the
> > > instruction
> > >
> > > This simplification will also make it easier to integrate dynamic patching
> > > in a follow-up patch. Indeed, the callback address should be in
> > > an original region and not re-mapped only which is writeable
> > > non-executable.
> > >
> > > This is part of XSA-263.
> > >
> > > Signed-off-by: Julien Grall
> > > Reviewed-by: Stefano Stabellini
> > >
> > > ---
> > >
> > > Cc: Konrad Rzeszutek Wilk
> > >
> > > Changes in v3:
> > > - Add stefano's reviewed-by
> > >
> > > Changes in v2:
> > > - Add commit message
> > > - Remove comment in the code that does not make sense anymore
> > > ---
> > > xen/arch/arm/alternative.c | 42
> > > +-
> > > 1 file changed, 13 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> > > index 9ffdc475d6..936cf04956 100644
> > > --- a/xen/arch/arm/alternative.c
> > > +++ b/xen/arch/arm/alternative.c
> > > @@ -97,12 +97,16 @@ static u32 get_alt_insn(const struct alt_instr *alt,
> > > /*
> > >* The region patched should be read-write to allow __apply_alternatives
> > >* to replacing the instructions when necessary.
> > > + *
> > > + * @update_offset: Offset between the region patched and the writable
> > > + * region for the update. 0 if the patched region is writable.
> > >*/
> > > -static int __apply_alternatives(const struct alt_region *region)
> > > +static int __apply_alternatives(const struct alt_region *region,
> > > +paddr_t update_offset)
> > > {
> > > const struct alt_instr *alt;
> > > -const u32 *replptr;
> > > -u32 *origptr;
> > > +const u32 *replptr, *origptr;
> > > +u32 *updptr;
> > > printk(XENLOG_INFO "alternatives: Patching with alt table %p ->
> > > %p\n",
> > > region->begin, region->end);
> > > @@ -118,6 +122,7 @@ static int __apply_alternatives(const struct
> > > alt_region *region)
> > > BUG_ON(alt->alt_len != alt->orig_len);
> > > origptr = ALT_ORIG_PTR(alt);
> > > +updptr = (void *)origptr + update_offset;
> > > replptr = ALT_REPL_PTR(alt);
> > > nr_inst = alt->alt_len / sizeof(insn);
> > > @@ -125,7 +130,7 @@ static int __apply_alternatives(const struct
> > > alt_region *region)
> > > for ( i = 0; i < nr_inst; i++ )
> > > {
> > > insn = get_alt_insn(alt, origptr + i, replptr + i);
> > > -*(origptr + i) = cpu_to_le32(insn);
> > > +*(updptr + i) = cpu_to_le32(insn);
> > > }
> > > /* Ensure the new instructions reached the memory and nuke */
> > > @@ -162,9 +167,6 @@ static int __apply_alternatives_multi_stop(void
> > > *unused)
> > > paddr_t xen_size = _end - _start;
> > > unsigned int xen_order = get_order_from_bytes(xen_size);
> > > void *xenmap;
> > > -struct virtual_region patch_region = {
> > > -.list = LIST_HEAD_INIT(patch_region.list),
> > > -};
> > > BUG_ON(patched);
> > > @@ -177,31 +179,13 @@ static int __apply_alternatives_multi_stop(void
> > > *unused)
> > > /* Re-mapping Xen is not expected to fail during boot. */
> > > BUG_ON(!xenmap);
> > > -/*
> > > - * If we generate a new branch instruction, the target will be
> > > - * calculated in this re-mapped Xen region. So we have to
> > > register
> > > - * this re-mapped Xen region as a virtual region temporarily.
> >
> > What about this?
> >
> > Won't this mean the traps (if there are any) won't be recognized at all
> > during this patching?
>
> What do you mean by recognized? This new region will only be accessed to
> write instruction. The only potential fault on that region is a data abort.
Exactly the data abort.
My recollection is that the data abort would print a stack trace. And
the stack trace needs symbol information - which it gets from virtual_region.
But if virtual_region is not registered then the stack won't contain the
name of the function that had an d
Re: [Xen-devel] [PATCH v3 4/6] vpt: split part of pt_intr_post into a separate helper
>>> On 08.06.18 at 17:07, wrote:
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Assuming a subsequent patch re-uses the function
Acked-by: Jan Beulich
It would be nice though to convert ...
> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -265,6 +265,41 @@ static void pt_timer_fn(void *data)
> pt_unlock(pt);
> }
>
> +static void pt_irq_fired(struct vcpu *v, struct periodic_time *pt)
> +{
> +pt->irq_issued = 0;
... this and ...
> +if ( pt->one_shot )
> +{
> +if ( pt->on_list )
> +list_del(&pt->list);
> +pt->on_list = 0;
... this to "false" in the course of moving the code. Once again an
adjustment that perhaps can be done while committing.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 5/6] vpt: add support for level interrupts
>>> On 08.06.18 at 17:07, wrote:
> @@ -316,7 +317,9 @@ int pt_update_irq(struct vcpu *v)
> if ( pt->pending_intr_nr )
> {
> /* RTC code takes care of disabling the timer itself. */
> -if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt) )
> +if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt) &&
> + /* Level interrupts should be asserted even if masked. */
> + !pt->level )
> {
> /* suspend timer emulation */
Especially with this comment I'm not convinced this change is fully
correct: Once a level triggered interrupt is latched in IRR, no
further assertions are meaningful, and hence emulation could (and
hence should) still be stopped to reduce resource consumption.
> @@ -374,13 +378,36 @@ int pt_update_irq(struct vcpu *v)
> break;
>
> case PTSRC_ioapic:
> -/*
> - * NB: At the moment IO-APIC routed interrupts generated by vpt
> devices
> - * (HPET) are edge-triggered.
> - */
> -pt_vector = hvm_ioapic_assert(v->domain, irq, false);
> +pt_vector = hvm_ioapic_assert(v->domain, irq, level);
> if ( pt_vector < 0 || !vlapic_test_irq(vcpu_vlapic(v), pt_vector) )
> +{
> pt_vector = -1;
> +if ( level )
> +{
> +/*
> + * Level interrupts are asserted even if the interrupt is
> + * masked, so also execute the callback associated with the
> + * timer.
> + */
> +time_cb *cb = NULL;
> +void *cb_priv;
> +
> +spin_lock(&v->arch.hvm_vcpu.tm_lock);
> +/* Make sure the timer is still on the list. */
> +list_for_each_entry ( pt, &v->arch.hvm_vcpu.tm_list, list )
> +if ( pt == earliest_pt )
> +{
> +pt_irq_fired(v, pt);
> +cb = pt->cb;
> +cb_priv = pt->priv;
> +break;
> +}
> +spin_unlock(&v->arch.hvm_vcpu.tm_lock);
> +
> +if ( cb != NULL )
> +cb(v, cb_priv);
> +}
> +}
> break;
I'm not fully convinced, especially in the case that hvm_ioapic_assert()
returned a negative value: Either the callback needs to be called in all
cases (even if an edge triggered interrupt was not successfully asserted),
or only when an interrupt really gets surfaced to the guest.
> @@ -447,12 +474,13 @@ void pt_migrate(struct vcpu *v)
>
> void create_periodic_time(
> struct vcpu *v, struct periodic_time *pt, uint64_t delta,
> -uint64_t period, uint8_t irq, time_cb *cb, void *data)
> +uint64_t period, uint8_t irq, time_cb *cb, void *data, bool level)
> {
> if ( !pt->source ||
> (irq >= NR_ISAIRQS && pt->source == PTSRC_isa) ||
> (irq >= hvm_domain_irq(v->domain)->nr_gsis &&
> - pt->source == PTSRC_ioapic) )
> + pt->source == PTSRC_ioapic) ||
> + (level && pt->source != PTSRC_ioapic) )
Could I talk you into avoiding the double checking against PTSRC_ioapic,
by using a conditional expression?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] strange behavior with Multiboot2 on EFI
What I did so far:
Installed Arch Linux inside of Qemu virtual machine.
Inside of virtual machine I added these lines to /etc/default/grub
GRUB_TERMINAL="serial"
GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1"
and called grub-mkconfig -o /boot/grub/grub.cfg
Now when I boot my virtual machine the Grub2 uses serial console.
I mounted EFI partition of virtual machine and copied into it Xen
kernel with multiboot2 support, and added following lines to
/mountpoint/grub/grub.cfg
menuentry 'Xen kernel' {
set root='(hd0,1)'
multiboot2 /xen
}
Now I am ready to launch Xen kernel inside my virtual machine.
I launch virtual machine with following command:
sudo qemu-system-x86_64 \
-hda linux.img \
-bios OVMF-pure-efi.fd \
-m 4096 \
-debugcon file:debug.log -global isa-debugcon.iobase=0x402
After choosing Xen kernel entry the following output goes to serial console:
error: no suitable video mode found.
Here is the tail of debug.log file:
[Bds]Booting GRUB
FSOpen: Open '\EFI\GRUB\grubx64.efi' Success
[Bds] Expand
HD(1,GPT,EBFF2C69-F2EF-4739-9CDA-2C83CB001691,0x800,0x1FF800)/\EFI\GRUB\grubx64.efi
->
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)/HD(1,GPT,EBFF2C69-F2EF-4739-9CDA-2C83CB001691,0x800,0x1FF800)/\EFI\GRU
BBY\grubx64.efi
[Security] 3rd party image[0] can be loaded after EndOfDxe:
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)/HD(1,GPT,EBFF2C69-F2EF-4739-9CDA-2C83CB001691,0x800,0x1FF800)/\EFI\GRUB\grubx64.efi.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BF2216C0
Loading driver at 0x000BE5CF000 EntryPoint=0x000BE5CF400
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BF29B518
ProtectUefiImageCommon - 0xBF2216C0
- 0xBE5CF000 - 0x0001DC00
ASSERT
/home/jenkins/workspace/edk2/rpms/build/edk2-gc2d6e2bc12/MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c(4773):
CR has Bad Signature
Qemu version is fresh enough:
$ qemu-system-x86_64 --version
QEMU emulator version 2.12.0
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
I tried to debug Qemu and it didn't even break in 0x3fd05e, the entry
point of Xen kernel.
Maybe I should recompile Grub2 myself instead using the one supplied
by Arch Linux?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 test] 124532: regressions - FAIL
flight 124532 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/124532/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 122969 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 122969 test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 122969 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-bootfail REGR. vs. 122969 test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 122969 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 122969 test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 122969 test-amd64-amd64-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 122969 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 122969 test-amd64-amd64-examine 8 reboot fail REGR. vs. 122969 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 122969 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 6 xen-installfail pass in 124460 test-armhf-armhf-libvirt 7 xen-boot fail pass in 124460 test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail pass in 124460 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 7 xen-boot fail REGR. vs. 122969 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt13 migrate-support-check fail in 124460 never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail in 124460 never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 124460 never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 124460 never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122969 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122969 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail never pass test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 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 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-amd64-i386-libvirt-q
[Xen-devel] [GIT PULL] xen: fixes for 4.18-rc2
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.18-rc2-tag
xen: fixes for 4.18-rc2
It contains the following fixes/cleanups:
- the removal of a BUG_ON() which wasn't necessary and which could
trigger now due to a recent change
- a correction of a long standing bug happening very rarely in Xen
dom0 when a hypercall buffer from user land was not accessible by
the hypervisor for very short periods of time due to e.g. page
migration or compaction
- usage of EXPORT_SYMBOL_GPL() instead EXPORT_SYMBOL() in a Xen-related
driver (no breakage possible as using those symbols without others
already exported via EXPORT-SYMBOL_GPL() wouldn't make any sense)
- a simplification for Xen PVH or Xen ARM guests
- some additional error handling for callers of xenbus_printf()
Thanks.
Juergen
arch/arm/xen/enlighten.c | 7 +-
arch/x86/xen/enlighten.c | 7 ++
arch/x86/xen/enlighten_pv.c | 1 +
arch/x86/xen/enlighten_pvh.c | 1 +
drivers/scsi/xen-scsifront.c | 33 --
drivers/xen/Makefile | 2 +-
drivers/xen/events/events_base.c | 2 -
drivers/xen/grant-table.c| 4 +-
drivers/xen/manage.c | 18 +++-
drivers/xen/privcmd-buf.c| 210 +++
drivers/xen/privcmd.c| 9 ++
drivers/xen/privcmd.h| 3 +
drivers/xen/xen-scsiback.c | 16 ++-
include/xen/xen.h| 6 +-
14 files changed, 297 insertions(+), 22 deletions(-)
Boris Ostrovsky (1):
xen: Remove unnecessary BUG_ON from __unbind_from_irq()
Juergen Gross (2):
xen: add new hypercall buffer mapping device
Oleksandr Andrushchenko (1):
xen/grant-table: Export gnttab_{alloc|free}_pages as GPL
Roger Pau Monne (1):
xen: share start flags between PV and PVH
Zhouyang Jia (3):
xen: add error handling for xenbus_printf
scsi: xen-scsifront: add error handling for xenbus_printf
xen/scsiback: add error handling for xenbus_printf
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 6/6] vhpet: add support for level triggered interrupts
>>> On 08.06.18 at 17:07, wrote:
> --- a/xen/arch/x86/hvm/hpet.c
> +++ b/xen/arch/x86/hvm/hpet.c
> @@ -223,6 +223,17 @@ static void hpet_stop_timer(HPETState *h, unsigned int
> tn,
> hpet_get_comparator(h, tn, guest_time);
> }
>
> +static void hpet_timer_fired(struct vcpu *v, void *data)
> +{
> +unsigned int tn = (unsigned int)data;
I don't think this cast will go through without warning on all gcc versions we
care about.
> +HPETState *h = vcpu_vhpet(v);
> +
> +write_lock(&h->lock);
> +ASSERT(!test_bit(tn, &h->hpet.isr));
> +__set_bit(tn, &h->hpet.isr);
if ( __test_and_set_bit() )
ASSERT_UNREACHABLE();
?
Seeing this I can understand why you want to call the callback the way
you do in the previous patch. I continue to be unconvinced this second
call is generally correct (and sufficient). Simply consider the RTC case,
where in theory the IRQ could also be level triggered.
> @@ -394,6 +411,32 @@ static int hpet_write(
> }
> break;
>
> +case HPET_STATUS:
> +/* write 1 to clear. */
> +while ( new_val )
> +{
> +bool active;
> +
> +i = find_first_set_bit(new_val);
> +if ( i >= HPET_TIMER_NUM )
> +break;
> +__clear_bit(i, &new_val);
> +active = __test_and_clear_bit(i, &h->hpet.isr);
> +if ( active )
> +{
> +/*
> + * Should pt->irq better be used here in case the guest
> changes
> + * the configured IRQ while it's active? Guest changing the
> IRQ
> + * while the interrupt is active is not documented.
> + */
I think it's better the way you have it, to base things on what is recorded
in h->hpet.isr. After all that's what has been asserted. In fact I don't see
how using pt->irq would address the situation: Isn't it that what changes
first, and hence the de-assert done here would go out of sync with the
prior assert?
> +hvm_ioapic_deassert(v->domain, timer_int_route(h, i));
> +if ( hpet_enabled(h) && timer_enabled(h, i) &&
> + timer_level(h, i) && timer_is_periodic(h, i) )
> +set_start_timer(i);
> +}
> +}
> +break;
What I'm wondering though: Does there really need to be a loop here?
How would more than one bit get set in h->hpet.isr?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
From: Michal Hocko
There are several blockable mmu notifiers which might sleep in
mmu_notifier_invalidate_range_start and that is a problem for the
oom_reaper because it needs to guarantee a forward progress so it cannot
depend on any sleepable locks. Currently we simply back off and mark an
oom victim with blockable mmu notifiers as done after a short sleep.
That can result in selecting a new oom victim prematurely because the
previous one still hasn't torn its memory down yet.
We can do much better though. Even if mmu notifiers use sleepable locks
there is no reason to automatically assume those locks are held.
Moreover most notifiers only care about a portion of the address
space. This patch handles the first part of the problem.
__mmu_notifier_invalidate_range_start gets a blockable flag and
callbacks are not allowed to sleep if the flag is set to false. This is
achieved by using trylock instead of the sleepable lock for most
callbacks. I think we can improve that even further because there is
a common pattern to do a range lookup first and then do something about
that. The first part can be done without a sleeping lock I presume.
Anyway, what does the oom_reaper do with all that? We do not have to
fail right away. We simply retry if there is at least one notifier which
couldn't make any progress. A retry loop is already implemented to wait
for the mmap_sem and this is basically the same thing.
Cc: "David (ChunMing) Zhou"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: Mike Marciniszyn
Cc: Dennis Dalessandro
Cc: Sudeep Dutt
Cc: Ashutosh Dixit
Cc: Dimitri Sivanich
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: "Jérôme Glisse"
Cc: Andrea Arcangeli
Cc: k...@vger.kernel.org (open list:KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86))
Cc: linux-ker...@vger.kernel.org (open list:X86 ARCHITECTURE (32-BIT AND
64-BIT))
Cc: amd-...@lists.freedesktop.org (open list:RADEON and AMDGPU DRM DRIVERS)
Cc: dri-de...@lists.freedesktop.org (open list:DRM DRIVERS)
Cc: intel-...@lists.freedesktop.org (open list:INTEL DRM DRIVERS (excluding
Poulsbo, Moorestow...)
Cc: linux-r...@vger.kernel.org (open list:INFINIBAND SUBSYSTEM)
Cc: xen-devel@lists.xenproject.org (moderated list:XEN HYPERVISOR INTERFACE)
Cc: linux...@kvack.org (open list:HMM - Heterogeneous Memory Management)
Reported-by: David Rientjes
Signed-off-by: Michal Hocko
---
Hi,
this is an RFC and not tested at all. I am not very familiar with the
mmu notifiers semantics very much so this is a crude attempt to achieve
what I need basically. It might be completely wrong but I would like
to discuss what would be a better way if that is the case.
get_maintainers gave me quite large list of people to CC so I had to trim
it down. If you think I have forgot somebody, please let me know
Any feedback is highly appreciated.
arch/x86/kvm/x86.c | 7 --
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 33 +++--
drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +---
drivers/gpu/drm/radeon/radeon_mn.c | 15 ---
drivers/infiniband/core/umem_odp.c | 15 ---
drivers/infiniband/hw/hfi1/mmu_rb.c | 7 --
drivers/misc/mic/scif/scif_dma.c| 7 --
drivers/misc/sgi-gru/grutlbpurge.c | 7 --
drivers/xen/gntdev.c| 14 ---
include/linux/kvm_host.h| 2 +-
include/linux/mmu_notifier.h| 15 +--
mm/hmm.c| 7 --
mm/mmu_notifier.c | 15 ---
mm/oom_kill.c | 29 +++---
virt/kvm/kvm_main.c | 12 ++---
15 files changed, 137 insertions(+), 58 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6bcecc325e7e..ac08f5d711be 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7203,8 +7203,9 @@ static void vcpu_load_eoi_exitmap(struct kvm_vcpu *vcpu)
kvm_x86_ops->load_eoi_exitmap(vcpu, eoi_exit_bitmap);
}
-void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
- unsigned long start, unsigned long end)
+int kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
+ unsigned long start, unsigned long end,
+ bool blockable)
{
unsigned long apic_address;
@@ -7215,6 +7216,8 @@ void kvm_arch_mmu_notifier_invalidate_range(struct kvm
*kvm,
apic_address = gfn_to_hva(kvm, APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
if (start <= apic_address && apic_address < end)
kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD);
+
+ return 0;
}
void kvm_vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
index 83e344fbb50a..d138a526feff 100644
--- a/drivers/
Re: [Xen-devel] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Hi Michal, [Adding Felix as well] Well first of all you have a misconception why at least the AMD graphics driver need to be able to sleep in an MMU notifier: We need to sleep because we need to wait for hardware operations to finish and *NOT* because we need to wait for locks. I'm not sure if your flag now means that you generally can't sleep in MMU notifiers any more, but if that's the case at least AMD hardware will break badly. In our case the approach of waiting for a short time for the process to be reaped and then select another victim actually sounds like the right thing to do. What we also already try to do is to abort hardware operations with the address space when we detect that the process is dying, but that can certainly be improved. Regards, Christian. Am 22.06.2018 um 17:02 schrieb Michal Hocko: From: Michal Hocko There are several blockable mmu notifiers which might sleep in mmu_notifier_invalidate_range_start and that is a problem for the oom_reaper because it needs to guarantee a forward progress so it cannot depend on any sleepable locks. Currently we simply back off and mark an oom victim with blockable mmu notifiers as done after a short sleep. That can result in selecting a new oom victim prematurely because the previous one still hasn't torn its memory down yet. We can do much better though. Even if mmu notifiers use sleepable locks there is no reason to automatically assume those locks are held. Moreover most notifiers only care about a portion of the address space. This patch handles the first part of the problem. __mmu_notifier_invalidate_range_start gets a blockable flag and callbacks are not allowed to sleep if the flag is set to false. This is achieved by using trylock instead of the sleepable lock for most callbacks. I think we can improve that even further because there is a common pattern to do a range lookup first and then do something about that. The first part can be done without a sleeping lock I presume. Anyway, what does the oom_reaper do with all that? We do not have to fail right away. We simply retry if there is at least one notifier which couldn't make any progress. A retry loop is already implemented to wait for the mmap_sem and this is basically the same thing. Cc: "David (ChunMing) Zhou" Cc: Paolo Bonzini Cc: "Radim Krčmář" Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Doug Ledford Cc: Jason Gunthorpe Cc: Mike Marciniszyn Cc: Dennis Dalessandro Cc: Sudeep Dutt Cc: Ashutosh Dixit Cc: Dimitri Sivanich Cc: Boris Ostrovsky Cc: Juergen Gross Cc: "Jérôme Glisse" Cc: Andrea Arcangeli Cc: k...@vger.kernel.org (open list:KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)) Cc: linux-ker...@vger.kernel.org (open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)) Cc: amd-...@lists.freedesktop.org (open list:RADEON and AMDGPU DRM DRIVERS) Cc: dri-de...@lists.freedesktop.org (open list:DRM DRIVERS) Cc: intel-...@lists.freedesktop.org (open list:INTEL DRM DRIVERS (excluding Poulsbo, Moorestow...) Cc: linux-r...@vger.kernel.org (open list:INFINIBAND SUBSYSTEM) Cc: xen-devel@lists.xenproject.org (moderated list:XEN HYPERVISOR INTERFACE) Cc: linux...@kvack.org (open list:HMM - Heterogeneous Memory Management) Reported-by: David Rientjes Signed-off-by: Michal Hocko --- Hi, this is an RFC and not tested at all. I am not very familiar with the mmu notifiers semantics very much so this is a crude attempt to achieve what I need basically. It might be completely wrong but I would like to discuss what would be a better way if that is the case. get_maintainers gave me quite large list of people to CC so I had to trim it down. If you think I have forgot somebody, please let me know Any feedback is highly appreciated. arch/x86/kvm/x86.c | 7 -- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 33 +++-- drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +--- drivers/gpu/drm/radeon/radeon_mn.c | 15 --- drivers/infiniband/core/umem_odp.c | 15 --- drivers/infiniband/hw/hfi1/mmu_rb.c | 7 -- drivers/misc/mic/scif/scif_dma.c| 7 -- drivers/misc/sgi-gru/grutlbpurge.c | 7 -- drivers/xen/gntdev.c| 14 --- include/linux/kvm_host.h| 2 +- include/linux/mmu_notifier.h| 15 +-- mm/hmm.c| 7 -- mm/mmu_notifier.c | 15 --- mm/oom_kill.c | 29 +++--- virt/kvm/kvm_main.c | 12 ++--- 15 files changed, 137 insertions(+), 58 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 6bcecc325e7e..ac08f5d711be 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7203,8 +7203,9 @@ static void vcpu_load_eoi_exitmap(struct kvm_vcpu *vcpu) kvm_x86_ops->load_eoi_exitmap(vcpu, e
Re: [Xen-devel] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Fri 22-06-18 17:13:02, Christian König wrote:
> Hi Michal,
>
> [Adding Felix as well]
>
> Well first of all you have a misconception why at least the AMD graphics
> driver need to be able to sleep in an MMU notifier: We need to sleep because
> we need to wait for hardware operations to finish and *NOT* because we need
> to wait for locks.
>
> I'm not sure if your flag now means that you generally can't sleep in MMU
> notifiers any more, but if that's the case at least AMD hardware will break
> badly. In our case the approach of waiting for a short time for the process
> to be reaped and then select another victim actually sounds like the right
> thing to do.
Well, I do not need to make the notifier code non blocking all the time.
All I need is to ensure that it won't sleep if the flag says so and
return -EAGAIN instead.
So here is what I do for amdgpu:
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > index 83e344fbb50a..d138a526feff 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > @@ -136,12 +136,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> >*
> >* Take the rmn read side lock.
> >*/
> > -static void amdgpu_mn_read_lock(struct amdgpu_mn *rmn)
> > +static int amdgpu_mn_read_lock(struct amdgpu_mn *rmn, bool blockable)
> > {
> > - mutex_lock(&rmn->read_lock);
> > + if (blockable)
> > + mutex_lock(&rmn->read_lock);
> > + else if (!mutex_trylock(&rmn->read_lock))
> > + return -EAGAIN;
> > +
> > if (atomic_inc_return(&rmn->recursion) == 1)
> > down_read_non_owner(&rmn->lock);
> > mutex_unlock(&rmn->read_lock);
> > +
> > + return 0;
> > }
> > /**
> > @@ -197,10 +203,11 @@ static void amdgpu_mn_invalidate_node(struct
> > amdgpu_mn_node *node,
> >* We block for all BOs between start and end to be idle and
> >* unmap them by move them into system domain again.
> >*/
> > -static void amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
> > +static int amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
> > struct mm_struct *mm,
> > unsigned long start,
> > -unsigned long end)
> > +unsigned long end,
> > +bool blockable)
> > {
> > struct amdgpu_mn *rmn = container_of(mn, struct amdgpu_mn, mn);
> > struct interval_tree_node *it;
> > @@ -208,7 +215,11 @@ static void
> > amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
> > /* notification is exclusive, but interval is inclusive */
> > end -= 1;
> > - amdgpu_mn_read_lock(rmn);
> > + /* TODO we should be able to split locking for interval tree and
> > +* amdgpu_mn_invalidate_node
> > +*/
> > + if (amdgpu_mn_read_lock(rmn, blockable))
> > + return -EAGAIN;
> > it = interval_tree_iter_first(&rmn->objects, start, end);
> > while (it) {
> > @@ -219,6 +230,8 @@ static void amdgpu_mn_invalidate_range_start_gfx(struct
> > mmu_notifier *mn,
> > amdgpu_mn_invalidate_node(node, start, end);
> > }
> > +
> > + return 0;
> > }
> > /**
> > @@ -233,10 +246,11 @@ static void
> > amdgpu_mn_invalidate_range_start_gfx(struct mmu_notifier *mn,
> >* necessitates evicting all user-mode queues of the process. The BOs
> >* are restorted in amdgpu_mn_invalidate_range_end_hsa.
> >*/
> > -static void amdgpu_mn_invalidate_range_start_hsa(struct mmu_notifier *mn,
> > +static int amdgpu_mn_invalidate_range_start_hsa(struct mmu_notifier *mn,
> > struct mm_struct *mm,
> > unsigned long start,
> > -unsigned long end)
> > +unsigned long end,
> > +bool blockable)
> > {
> > struct amdgpu_mn *rmn = container_of(mn, struct amdgpu_mn, mn);
> > struct interval_tree_node *it;
> > @@ -244,7 +258,8 @@ static void amdgpu_mn_invalidate_range_start_hsa(struct
> > mmu_notifier *mn,
> > /* notification is exclusive, but interval is inclusive */
> > end -= 1;
> > - amdgpu_mn_read_lock(rmn);
> > + if (amdgpu_mn_read_lock(rmn, blockable))
> > + return -EAGAIN;
> > it = interval_tree_iter_first(&rmn->objects, start, end);
> > while (it) {
> > @@ -262,6 +277,8 @@ static void amdgpu_mn_invalidate_range_start_hsa(struct
> > mmu_notifier *mn,
> > amdgpu_amdkfd_evict_userptr(mem, mm);
> > }
> > }
> > +
> > + return 0;
> > }
> > /**
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenpro
Re: [Xen-devel] [PATCH v3 5/6] vpt: add support for level interrupts
On Fri, Jun 22, 2018 at 08:23:02AM -0600, Jan Beulich wrote:
> >>> On 08.06.18 at 17:07, wrote:
> > @@ -316,7 +317,9 @@ int pt_update_irq(struct vcpu *v)
> > if ( pt->pending_intr_nr )
> > {
> > /* RTC code takes care of disabling the timer itself. */
> > -if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt) )
> > +if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt) &&
> > + /* Level interrupts should be asserted even if masked. */
> > + !pt->level )
> > {
> > /* suspend timer emulation */
>
> Especially with this comment I'm not convinced this change is fully
> correct: Once a level triggered interrupt is latched in IRR, no
> further assertions are meaningful, and hence emulation could (and
> hence should) still be stopped to reduce resource consumption.
Hm, I can see your point, but that's going to make the implementation
of HPET level trigger interrupts more complex.
From my reading of the spec, when a level triggered HPET interrupt
fires the ISR bit must be set, regardless of whether the IRR of the
io-apic entry is set or not.
Maybe the right solution is to add a pt_irq_pending that checks the
IRR bit, and a new flag that the caller can set in order to requests
callbacks regardless of whether the interrupt has been injected or
not. Would you agree to that plan?
> > @@ -374,13 +378,36 @@ int pt_update_irq(struct vcpu *v)
> > break;
> >
> > case PTSRC_ioapic:
> > -/*
> > - * NB: At the moment IO-APIC routed interrupts generated by vpt
> > devices
> > - * (HPET) are edge-triggered.
> > - */
> > -pt_vector = hvm_ioapic_assert(v->domain, irq, false);
> > +pt_vector = hvm_ioapic_assert(v->domain, irq, level);
> > if ( pt_vector < 0 || !vlapic_test_irq(vcpu_vlapic(v), pt_vector) )
> > +{
> > pt_vector = -1;
> > +if ( level )
> > +{
> > +/*
> > + * Level interrupts are asserted even if the interrupt is
> > + * masked, so also execute the callback associated with the
> > + * timer.
> > + */
> > +time_cb *cb = NULL;
> > +void *cb_priv;
> > +
> > +spin_lock(&v->arch.hvm_vcpu.tm_lock);
> > +/* Make sure the timer is still on the list. */
> > +list_for_each_entry ( pt, &v->arch.hvm_vcpu.tm_list, list )
> > +if ( pt == earliest_pt )
> > +{
> > +pt_irq_fired(v, pt);
> > +cb = pt->cb;
> > +cb_priv = pt->priv;
> > +break;
> > +}
> > +spin_unlock(&v->arch.hvm_vcpu.tm_lock);
> > +
> > +if ( cb != NULL )
> > +cb(v, cb_priv);
> > +}
> > +}
> > break;
>
> I'm not fully convinced, especially in the case that hvm_ioapic_assert()
> returned a negative value: Either the callback needs to be called in all
> cases (even if an edge triggered interrupt was not successfully asserted),
> or only when an interrupt really gets surfaced to the guest.
See my proposal above for adding a new option to signal whether the
callback should be executed regardless of whether interrupt injection
succeeded or not.
>
> > @@ -447,12 +474,13 @@ void pt_migrate(struct vcpu *v)
> >
> > void create_periodic_time(
> > struct vcpu *v, struct periodic_time *pt, uint64_t delta,
> > -uint64_t period, uint8_t irq, time_cb *cb, void *data)
> > +uint64_t period, uint8_t irq, time_cb *cb, void *data, bool level)
> > {
> > if ( !pt->source ||
> > (irq >= NR_ISAIRQS && pt->source == PTSRC_isa) ||
> > (irq >= hvm_domain_irq(v->domain)->nr_gsis &&
> > - pt->source == PTSRC_ioapic) )
> > + pt->source == PTSRC_ioapic) ||
> > + (level && pt->source != PTSRC_ioapic) )
>
> Could I talk you into avoiding the double checking against PTSRC_ioapic,
> by using a conditional expression?
So something like:
pt->source == PTSRC_ioapic ? irq >= hvm_domain_irq(v->domain)->nr_gsis : level
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH V2 2/2] x86/altp2m: Fixed domain crash with INVALID_ALTP2M EPTP index
>>> On 13.06.18 at 10:52, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3592,7 +3592,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> }
> }
>
> -if ( idx != vcpu_altp2m(v).p2midx )
> +if ( idx != INVALID_ALTP2M && idx != vcpu_altp2m(v).p2midx )
> {
> BUG_ON(idx >= MAX_ALTP2M);
In the code immediately ahead of this there is an INVALID_ALTP2M check
already (in the else branch). If the __vmread() can legitimately produce
this value, why would the domain be crashed when getting back
INVALID_ALTP2M in the other case? I think the correctness of your change
can only be judged once both code paths behave consistently.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 6/6] vhpet: add support for level triggered interrupts
On Fri, Jun 22, 2018 at 09:00:27AM -0600, Jan Beulich wrote:
> >>> On 08.06.18 at 17:07, wrote:
> > --- a/xen/arch/x86/hvm/hpet.c
> > +++ b/xen/arch/x86/hvm/hpet.c
> > @@ -223,6 +223,17 @@ static void hpet_stop_timer(HPETState *h, unsigned int
> > tn,
> > hpet_get_comparator(h, tn, guest_time);
> > }
> >
> > +static void hpet_timer_fired(struct vcpu *v, void *data)
> > +{
> > +unsigned int tn = (unsigned int)data;
>
> I don't think this cast will go through without warning on all gcc versions we
> care about.
Hm, should be casted to unsigned long I guess so it's the same size.
> > +HPETState *h = vcpu_vhpet(v);
> > +
> > +write_lock(&h->lock);
> > +ASSERT(!test_bit(tn, &h->hpet.isr));
> > +__set_bit(tn, &h->hpet.isr);
>
> if ( __test_and_set_bit() )
> ASSERT_UNREACHABLE();
>
> ?
>
> Seeing this I can understand why you want to call the callback the way
> you do in the previous patch. I continue to be unconvinced this second
> call is generally correct (and sufficient). Simply consider the RTC case,
> where in theory the IRQ could also be level triggered.
See my reply to the other patch.
> > @@ -394,6 +411,32 @@ static int hpet_write(
> > }
> > break;
> >
> > +case HPET_STATUS:
> > +/* write 1 to clear. */
> > +while ( new_val )
> > +{
> > +bool active;
> > +
> > +i = find_first_set_bit(new_val);
> > +if ( i >= HPET_TIMER_NUM )
> > +break;
> > +__clear_bit(i, &new_val);
> > +active = __test_and_clear_bit(i, &h->hpet.isr);
> > +if ( active )
> > +{
> > +/*
> > + * Should pt->irq better be used here in case the guest
> > changes
> > + * the configured IRQ while it's active? Guest changing
> > the IRQ
> > + * while the interrupt is active is not documented.
> > + */
>
> I think it's better the way you have it, to base things on what is recorded
> in h->hpet.isr. After all that's what has been asserted. In fact I don't see
> how using pt->irq would address the situation: Isn't it that what changes
> first, and hence the de-assert done here would go out of sync with the
> prior assert?
What's in the HPET state can be changed by guest writes, so it might
be more accurate to use pt->irq, which is the IRQ that was asserted by
the vpt code. In any case, I'm not specially trilled because a guest
changing this while the interrupt is active is certainly asking for
trouble.
> > +hvm_ioapic_deassert(v->domain, timer_int_route(h, i));
> > +if ( hpet_enabled(h) && timer_enabled(h, i) &&
> > + timer_level(h, i) && timer_is_periodic(h, i) )
> > +set_start_timer(i);
> > +}
> > +}
> > +break;
>
> What I'm wondering though: Does there really need to be a loop here?
> How would more than one bit get set in h->hpet.isr?
The current HPET code exposes 3 timers, and all of them can be set to
level triggered, so in theory you could clear the 3 ISR bits with one
write, hence the loop.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Quoting Michal Hocko (2018-06-22 16:02:42)
> Hi,
> this is an RFC and not tested at all. I am not very familiar with the
> mmu notifiers semantics very much so this is a crude attempt to achieve
> what I need basically. It might be completely wrong but I would like
> to discuss what would be a better way if that is the case.
>
> get_maintainers gave me quite large list of people to CC so I had to trim
> it down. If you think I have forgot somebody, please let me know
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 854bd51b9478..5285df9331fa 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object *mo)
> mo->attached = false;
> }
>
> -static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier
> *_mn,
> +static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier
> *_mn,
>struct mm_struct *mm,
>unsigned long start,
> - unsigned long end)
> + unsigned long end,
> + bool blockable)
> {
> struct i915_mmu_notifier *mn =
> container_of(_mn, struct i915_mmu_notifier, mn);
> @@ -124,7 +125,7 @@ static void
> i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> LIST_HEAD(cancelled);
>
> if (RB_EMPTY_ROOT(&mn->objects.rb_root))
> - return;
> + return 0;
The principle wait here is for the HW (even after fixing all the locks
to be not so coarse, we still have to wait for the HW to finish its
access). The first pass would be then to not do anything here if
!blockable.
Jerome keeps on shaking his head and telling us we're doing it all
wrong, so maybe it'll all fall out of HMM before we have to figure out
how to differentiate between objects that can be invalidated immediately
and those that need to acquire locks and/or wait.
-Chris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2] x86/mm: Add mem access rights to NPT
>>> On 18.06.18 at 17:17, wrote:
> From: Isaila Alexandru
>
> This patch adds access rights for the NPT pages. The access rights are
> saved in a radix tree with the root saved in p2m_domain.
Sounds resource intensive. How many nodes would such a radix tree have
on average?
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -221,6 +221,9 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
> {
> req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
> req->u.mem_access.gla = gla;
> +}
> +if ( npfec.gla_valid || cpu_has_svm )
> +{
>
> if ( npfec.kind == npfec_kind_with_gla )
You leave a bogusly placed blank line. Please put it ahead of the if()
you add.
> @@ -112,8 +117,37 @@ static unsigned long p2m_type_to_flags(const struct
> p2m_domain *p2m,
> flags |= _PAGE_PWT;
> ASSERT(!level);
> }
> -return flags | P2M_BASE_FLAGS | _PAGE_PCD;
> +flags |= P2M_BASE_FLAGS | _PAGE_PCD;
> +break;
> +}
> +switch (access)
Coding style.
> +static void p2m_set_access(struct p2m_domain *p2m, unsigned long gfn,
> + p2m_access_t a)
> +{
> +int rc;
> +
> +if ( p2m_access_rwx == a )
> +radix_tree_delete(&p2m->mem_access_settings, gfn);
> +
> +rc = radix_tree_insert(&p2m->mem_access_settings, gfn,
> + radix_tree_int_to_ptr(a));
Is there an "else" missing above here? Otherwise why would you
delete the node first?
Also the access rights are far fewer bits than there can be stored in a
node. Did you consider clustering several GFNs' access rights into a
single node?
> @@ -750,7 +820,7 @@ p2m_pt_get_entry(struct p2m_domain *p2m, gfn_t gfn_,
> * XXX we will return p2m_invalid for unmapped gfns */
> *t = p2m_mmio_dm;
> /* Not implemented except with EPT */
> -*a = p2m_access_rwx;
> +*a = p2m_access_n;
And the comment remains nevertheless?
> @@ -1127,6 +1200,7 @@ void p2m_pt_init(struct p2m_domain *p2m)
> p2m->change_entry_type_global = p2m_pt_change_entry_type_global;
> p2m->change_entry_type_range = p2m_pt_change_entry_type_range;
> p2m->write_p2m_entry = paging_write_p2m_entry;
> +radix_tree_init(&p2m->mem_access_settings);
While I don't think there's a risk of races, wouldn't it be better anyway
to set up resources before installing hooks / callbacks?
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -675,6 +675,9 @@ void p2m_teardown(struct p2m_domain *p2m)
>
> d = p2m->domain;
>
> +if ( cpu_has_svm )
> +radix_tree_destroy(&p2m->mem_access_settings, NULL);
What about shadow mode, or SVM without NPT? The init above is not
conditional upon SVM, nor is any of the manipulation of the radix tree.
> --- a/xen/include/asm-x86/mem_access.h
> +++ b/xen/include/asm-x86/mem_access.h
> @@ -46,7 +46,7 @@ bool p2m_mem_access_emulate_check(struct vcpu *v,
> /* Sanity check for mem_access hardware support */
> static inline bool p2m_mem_access_sanity_check(struct domain *d)
> {
> -return is_hvm_domain(d) && cpu_has_vmx && hap_enabled(d);
> +return is_hvm_domain(d) && hap_enabled(d);
Considering this, should initialization and manipulation perhaps become
conditional upon hap_enabled(d) (perhaps implicitly by finding the radix
tree uninitialized)? Or even some more specific predicate, so that the
tree wouldn't be maintained at all unless someone cared about the
access rights?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 5/6] vpt: add support for level interrupts
>>> On 22.06.18 at 17:24, wrote:
> On Fri, Jun 22, 2018 at 08:23:02AM -0600, Jan Beulich wrote:
>> >>> On 08.06.18 at 17:07, wrote:
>> > @@ -316,7 +317,9 @@ int pt_update_irq(struct vcpu *v)
>> > if ( pt->pending_intr_nr )
>> > {
>> > /* RTC code takes care of disabling the timer itself. */
>> > -if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt) )
>> > +if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt) &&
>> > + /* Level interrupts should be asserted even if masked. */
>> > + !pt->level )
>> > {
>> > /* suspend timer emulation */
>>
>> Especially with this comment I'm not convinced this change is fully
>> correct: Once a level triggered interrupt is latched in IRR, no
>> further assertions are meaningful, and hence emulation could (and
>> hence should) still be stopped to reduce resource consumption.
>
> Hm, I can see your point, but that's going to make the implementation
> of HPET level trigger interrupts more complex.
>
> From my reading of the spec, when a level triggered HPET interrupt
> fires the ISR bit must be set, regardless of whether the IRR of the
> io-apic entry is set or not.
>
> Maybe the right solution is to add a pt_irq_pending that checks the
> IRR bit, and a new flag that the caller can set in order to requests
> callbacks regardless of whether the interrupt has been injected or
> not. Would you agree to that plan?
That sounds like a reasonable option. Another would be to add a
parameter to the callback allowing the context to be identified to the
callee.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-4.9 bisection] complete test-amd64-amd64-xl-qemut-ws16-amd64
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-ws16-amd64
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
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: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Bug introduced: bb70de1f993b5a7fffe9d42c68907b60ef5319a6
Bug not present: 474928b8f0a6ba49872ef2769610b80638820aad
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/124608/
commit bb70de1f993b5a7fffe9d42c68907b60ef5319a6
Author: Juergen Gross
Date: Wed May 30 13:09:57 2018 +0200
xen: set cpu capabilities from xen_start_kernel()
Upstream commit: 0808e80cb760de2733c0527d2090ed2205a1eef8 ("xen: set
cpu capabilities from xen_start_kernel()")
There is no need to set the same capabilities for each cpu
individually. This can easily be done for all cpus when starting the
kernel.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Signed-off-by: Greg Kroah-Hartman
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-4.9/test-amd64-amd64-xl-qemut-ws16-amd64.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-4.9/test-amd64-amd64-xl-qemut-ws16-amd64.xen-boot
--summary-out=tmp/124608.bisection-summary --basis-template=122969
--blessings=real,real-bisect linux-4.9 test-amd64-amd64-xl-qemut-ws16-amd64
xen-boot
Searching for failure / basis pass:
124532 fail [host=godello1] / 123819 ok.
Failure / basis pass flights: 124532 / 123819
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
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 8e52b94e19d82e2be4f3bf3699c8f39f4c6cc478
c530a75c1e6a472b0eb9558310b518f0dfcd8860
c8ea0457495342c417c3dc033bba25148b279f60
43139135a8938de44f66333831d3a8655d07663a
11535cdbc0ae5925a55b3e735447c30faaa6f63b
Basis pass 2460c23c35e9a612395b4108dbc19f3c1f016d43
c530a75c1e6a472b0eb9558310b518f0dfcd8860
c8ea0457495342c417c3dc033bba25148b279f60
43139135a8938de44f66333831d3a8655d07663a
06f542f8f2e446c01bd0edab51e9450af7f6e05b
Generating revisions with ./adhoc-revtuple-generator
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#2460c23c35e9a612395b4108dbc19f3c1f016d43-8e52b94e19d82e2be4f3bf3699c8f39f4c6cc478
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
git://xenbits.xen.org/qemu-xen.git#43139135a8938de44f66333831d3a8655d07663a-43139135a8938de44f66333831d3a8655d07663a
git://xenbits.xen.org/xen.git#06f542f8f2e446c01bd0edab51e9450af7f6e05b-11535cdbc0ae5925a55b3e735447c30faaa6f63b
Loaded 2001 nodes in revision graph
Searching for test results:
123819 pass 2460c23c35e9a612395b4108dbc19f3c1f016d43
c530a75c1e6a472b0eb9558310b518f0dfcd8860
c8ea0457495342c417c3dc033bba25148b279f60
43139135a8938de44f66333831d3a8655d07663a
06f542f8f2e446c01bd0edab51e9450af7f6e05b
123861 fail irrelevant
123970 fail irrelevant
123914 fail irrelevant
124033 fail irrelevant
124055 fail irrelevant
124084 fail 3c3d05fc6e6653bdf9f7fb3fb6922b199c7ba3ec
c530a75c1e6a472b0eb9558310b518f0dfcd8860
c8ea0457495342c417c3dc033bba25148b279f60
43139135a8938de44f66333831d3a8655d07663a
11535cdbc0ae5925a55b3e735447c30faaa6f63b
124113 fail 3c3d05fc6e6653bdf9f7fb3fb6922b199c7ba3ec
c530a75c1e6a472b0eb9558310b518f0dfcd8860
c8ea0457495342c417c3dc033bba25148b279f60
43139135a8938de44f66333831d3a8655d07663a
11535cdbc0ae5925a55b3e735447c30faaa6f63b
124190 fail 4f42dc62be92afe9863bf2598e6b0d637430f74f
c530a75c1e6a472b0eb9558310b518f0dfcd8860
c8ea0457495342c417c3dc033bba25148b279f60
43139135a8938de44f66333831d3a8655d07663a
11535cdbc0ae5925a55b3e735447c30faaa6f63b
124168 fail 3c3d05fc6e6653bdf9f7fb3fb6922b199c7ba3ec
c530a75c1e6a472b0eb9558310b518f0dfcd8860
c8ea0457495342c417c3dc033bba25148b279f60
43139135a8938de44f66333831d3a8655d07663a
11535cdbc0ae5925a55b3e735447c30faaa6f63b
124223 fail 4f42dc62be92afe9863bf2598e6b0d637430f74f
c530a75c1e6a472b0eb9558310b518f0dfcd8860
c8ea0457495342c417c3dc033bba25148b279f60
43139135a8938de44f66333831d3a8655d07663a
Re: [Xen-devel] [PATCH v3 5/6] vpt: add support for level interrupts
On Fri, Jun 22, 2018 at 09:53:26AM -0600, Jan Beulich wrote:
> >>> On 22.06.18 at 17:24, wrote:
> > On Fri, Jun 22, 2018 at 08:23:02AM -0600, Jan Beulich wrote:
> >> >>> On 08.06.18 at 17:07, wrote:
> >> > @@ -316,7 +317,9 @@ int pt_update_irq(struct vcpu *v)
> >> > if ( pt->pending_intr_nr )
> >> > {
> >> > /* RTC code takes care of disabling the timer itself. */
> >> > -if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt)
> >> > )
> >> > +if ( (pt->irq != RTC_IRQ || !pt->priv) && pt_irq_masked(pt)
> >> > &&
> >> > + /* Level interrupts should be asserted even if masked.
> >> > */
> >> > + !pt->level )
> >> > {
> >> > /* suspend timer emulation */
> >>
> >> Especially with this comment I'm not convinced this change is fully
> >> correct: Once a level triggered interrupt is latched in IRR, no
> >> further assertions are meaningful, and hence emulation could (and
> >> hence should) still be stopped to reduce resource consumption.
> >
> > Hm, I can see your point, but that's going to make the implementation
> > of HPET level trigger interrupts more complex.
> >
> > From my reading of the spec, when a level triggered HPET interrupt
> > fires the ISR bit must be set, regardless of whether the IRR of the
> > io-apic entry is set or not.
> >
> > Maybe the right solution is to add a pt_irq_pending that checks the
> > IRR bit, and a new flag that the caller can set in order to requests
> > callbacks regardless of whether the interrupt has been injected or
> > not. Would you agree to that plan?
>
> That sounds like a reasonable option. Another would be to add a
> parameter to the callback allowing the context to be identified to the
> callee.
Yes, but that seems less optimal since all callback will be executed
and current callers would just exit if the interrupt was masked. I
will add the new option an send a new version.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:02:42)
> > Hi,
> > this is an RFC and not tested at all. I am not very familiar with the
> > mmu notifiers semantics very much so this is a crude attempt to achieve
> > what I need basically. It might be completely wrong but I would like
> > to discuss what would be a better way if that is the case.
> >
> > get_maintainers gave me quite large list of people to CC so I had to trim
> > it down. If you think I have forgot somebody, please let me know
>
> > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > index 854bd51b9478..5285df9331fa 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object *mo)
> > mo->attached = false;
> > }
> >
> > -static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier
> > *_mn,
> > +static int i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier
> > *_mn,
> >struct mm_struct *mm,
> >unsigned long start,
> > - unsigned long end)
> > + unsigned long end,
> > + bool blockable)
> > {
> > struct i915_mmu_notifier *mn =
> > container_of(_mn, struct i915_mmu_notifier, mn);
> > @@ -124,7 +125,7 @@ static void
> > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > LIST_HEAD(cancelled);
> >
> > if (RB_EMPTY_ROOT(&mn->objects.rb_root))
> > - return;
> > + return 0;
>
> The principle wait here is for the HW (even after fixing all the locks
> to be not so coarse, we still have to wait for the HW to finish its
> access).
Is this wait bound or it can take basically arbitrary amount of time?
> The first pass would be then to not do anything here if
> !blockable.
something like this? (incremental diff)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 5285df9331fa..e9ed0d2cfabc 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -122,6 +122,7 @@ static int
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
container_of(_mn, struct i915_mmu_notifier, mn);
struct i915_mmu_object *mo;
struct interval_tree_node *it;
+ int ret = 0;
LIST_HEAD(cancelled);
if (RB_EMPTY_ROOT(&mn->objects.rb_root))
@@ -133,6 +134,10 @@ static int
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
spin_lock(&mn->lock);
it = interval_tree_iter_first(&mn->objects, start, end);
while (it) {
+ if (!blockable) {
+ ret = -EAGAIN;
+ goto out_unlock;
+ }
/* The mmu_object is released late when destroying the
* GEM object so it is entirely possible to gain a
* reference on an object in the process of being freed
@@ -154,8 +159,10 @@ static int
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
spin_unlock(&mn->lock);
/* TODO: can we skip waiting here? */
- if (!list_empty(&cancelled) && blockable)
+ if (!list_empty(&cancelled))
flush_workqueue(mn->wq);
+
+ return ret;
}
static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 6/6] vhpet: add support for level triggered interrupts
>>> On 22.06.18 at 17:31, wrote:
> On Fri, Jun 22, 2018 at 09:00:27AM -0600, Jan Beulich wrote:
>> >>> On 08.06.18 at 17:07, wrote:
>> > --- a/xen/arch/x86/hvm/hpet.c
>> > +++ b/xen/arch/x86/hvm/hpet.c
>> > @@ -223,6 +223,17 @@ static void hpet_stop_timer(HPETState *h, unsigned
>> > int
> tn,
>> > hpet_get_comparator(h, tn, guest_time);
>> > }
>> >
>> > +static void hpet_timer_fired(struct vcpu *v, void *data)
>> > +{
>> > +unsigned int tn = (unsigned int)data;
>>
>> I don't think this cast will go through without warning on all gcc versions
> we
>> care about.
>
> Hm, should be casted to unsigned long I guess so it's the same size.
>
>> > +HPETState *h = vcpu_vhpet(v);
>> > +
>> > +write_lock(&h->lock);
>> > +ASSERT(!test_bit(tn, &h->hpet.isr));
>> > +__set_bit(tn, &h->hpet.isr);
>>
>> if ( __test_and_set_bit() )
>> ASSERT_UNREACHABLE();
>>
>> ?
>>
>> Seeing this I can understand why you want to call the callback the way
>> you do in the previous patch. I continue to be unconvinced this second
>> call is generally correct (and sufficient). Simply consider the RTC case,
>> where in theory the IRQ could also be level triggered.
>
> See my reply to the other patch.
>
>> > @@ -394,6 +411,32 @@ static int hpet_write(
>> > }
>> > break;
>> >
>> > +case HPET_STATUS:
>> > +/* write 1 to clear. */
>> > +while ( new_val )
>> > +{
>> > +bool active;
>> > +
>> > +i = find_first_set_bit(new_val);
>> > +if ( i >= HPET_TIMER_NUM )
>> > +break;
>> > +__clear_bit(i, &new_val);
>> > +active = __test_and_clear_bit(i, &h->hpet.isr);
>> > +if ( active )
>> > +{
>> > +/*
>> > + * Should pt->irq better be used here in case the guest
>> > changes
>> > + * the configured IRQ while it's active? Guest changing
>> > the IRQ
>> > + * while the interrupt is active is not documented.
>> > + */
>>
>> I think it's better the way you have it, to base things on what is recorded
>> in h->hpet.isr. After all that's what has been asserted. In fact I don't see
>> how using pt->irq would address the situation: Isn't it that what changes
>> first, and hence the de-assert done here would go out of sync with the
>> prior assert?
>
> What's in the HPET state can be changed by guest writes,
Not exactly - the only way to modify h->hpet.isr is through the code above.
> so it might
> be more accurate to use pt->irq, which is the IRQ that was asserted by
> the vpt code.
I.e. I'm viewing it exactly the other way around - the guest can affect
pt->irq directly.
>> > +hvm_ioapic_deassert(v->domain, timer_int_route(h, i));
>> > +if ( hpet_enabled(h) && timer_enabled(h, i) &&
>> > + timer_level(h, i) && timer_is_periodic(h, i) )
>> > +set_start_timer(i);
>> > +}
>> > +}
>> > +break;
>>
>> What I'm wondering though: Does there really need to be a loop here?
>> How would more than one bit get set in h->hpet.isr?
>
> The current HPET code exposes 3 timers, and all of them can be set to
> level triggered, so in theory you could clear the 3 ISR bits with one
> write, hence the loop.
Oh, right, I was mislead by the comment above saying pt->irq when you
really mean pt[tn].irq
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 6/6] vhpet: add support for level triggered interrupts
On Fri, Jun 22, 2018 at 10:00:41AM -0600, Jan Beulich wrote:
> >>> On 22.06.18 at 17:31, wrote:
> > On Fri, Jun 22, 2018 at 09:00:27AM -0600, Jan Beulich wrote:
> >> >>> On 08.06.18 at 17:07, wrote:
> >> > --- a/xen/arch/x86/hvm/hpet.c
> >> > +++ b/xen/arch/x86/hvm/hpet.c
> >> > @@ -223,6 +223,17 @@ static void hpet_stop_timer(HPETState *h, unsigned
> >> > int
> > tn,
> >> > hpet_get_comparator(h, tn, guest_time);
> >> > }
> >> >
> >> > +static void hpet_timer_fired(struct vcpu *v, void *data)
> >> > +{
> >> > +unsigned int tn = (unsigned int)data;
> >>
> >> I don't think this cast will go through without warning on all gcc
> >> versions
> > we
> >> care about.
> >
> > Hm, should be casted to unsigned long I guess so it's the same size.
> >
> >> > +HPETState *h = vcpu_vhpet(v);
> >> > +
> >> > +write_lock(&h->lock);
> >> > +ASSERT(!test_bit(tn, &h->hpet.isr));
> >> > +__set_bit(tn, &h->hpet.isr);
> >>
> >> if ( __test_and_set_bit() )
> >> ASSERT_UNREACHABLE();
> >>
> >> ?
> >>
> >> Seeing this I can understand why you want to call the callback the way
> >> you do in the previous patch. I continue to be unconvinced this second
> >> call is generally correct (and sufficient). Simply consider the RTC case,
> >> where in theory the IRQ could also be level triggered.
> >
> > See my reply to the other patch.
> >
> >> > @@ -394,6 +411,32 @@ static int hpet_write(
> >> > }
> >> > break;
> >> >
> >> > +case HPET_STATUS:
> >> > +/* write 1 to clear. */
> >> > +while ( new_val )
> >> > +{
> >> > +bool active;
> >> > +
> >> > +i = find_first_set_bit(new_val);
> >> > +if ( i >= HPET_TIMER_NUM )
> >> > +break;
> >> > +__clear_bit(i, &new_val);
> >> > +active = __test_and_clear_bit(i, &h->hpet.isr);
> >> > +if ( active )
> >> > +{
> >> > +/*
> >> > + * Should pt->irq better be used here in case the guest
> >> > changes
> >> > + * the configured IRQ while it's active? Guest changing
> >> > the IRQ
> >> > + * while the interrupt is active is not documented.
> >> > + */
> >>
> >> I think it's better the way you have it, to base things on what is recorded
> >> in h->hpet.isr. After all that's what has been asserted. In fact I don't
> >> see
> >> how using pt->irq would address the situation: Isn't it that what changes
> >> first, and hence the de-assert done here would go out of sync with the
> >> prior assert?
> >
> > What's in the HPET state can be changed by guest writes,
>
> Not exactly - the only way to modify h->hpet.isr is through the code above.
Right, but ISR only signals which timer has fired, not which IRQ the
timer was using. That's stored in pt->irq or h->tn[n].irq, and it's
what Xen needs in order to perform the deassert.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > Quoting Michal Hocko (2018-06-22 16:02:42)
> > > Hi,
> > > this is an RFC and not tested at all. I am not very familiar with the
> > > mmu notifiers semantics very much so this is a crude attempt to achieve
> > > what I need basically. It might be completely wrong but I would like
> > > to discuss what would be a better way if that is the case.
> > >
> > > get_maintainers gave me quite large list of people to CC so I had to trim
> > > it down. If you think I have forgot somebody, please let me know
> >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > index 854bd51b9478..5285df9331fa 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object *mo)
> > > mo->attached = false;
> > > }
> > >
> > > -static void i915_gem_userptr_mn_invalidate_range_start(struct
> > > mmu_notifier *_mn,
> > > +static int i915_gem_userptr_mn_invalidate_range_start(struct
> > > mmu_notifier *_mn,
> > >struct mm_struct
> > > *mm,
> > >unsigned long
> > > start,
> > > - unsigned long end)
> > > + unsigned long end,
> > > + bool blockable)
> > > {
> > > struct i915_mmu_notifier *mn =
> > > container_of(_mn, struct i915_mmu_notifier, mn);
> > > @@ -124,7 +125,7 @@ static void
> > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > LIST_HEAD(cancelled);
> > >
> > > if (RB_EMPTY_ROOT(&mn->objects.rb_root))
> > > - return;
> > > + return 0;
> >
> > The principle wait here is for the HW (even after fixing all the locks
> > to be not so coarse, we still have to wait for the HW to finish its
> > access).
>
> Is this wait bound or it can take basically arbitrary amount of time?
Arbitrary amount of time but in desktop use case you can assume that
it should never go above 16ms for a 60frame per second rendering of
your desktop (in GPU compute case this kind of assumption does not
hold). Is the process exit_state already updated by the time this mmu
notifier callbacks happen ?
>
> > The first pass would be then to not do anything here if
> > !blockable.
>
> something like this? (incremental diff)
What i wanted to do with HMM and mmu notifier is split the invalidation
in 2 pass. First pass tell the drivers to stop/cancel pending jobs that
depends on the range and invalidate internal driver states (like clear
buffer object pages array in case of GPU but not GPU page table). While
the second callback would do the actual wait on the GPU to be done and
update the GPU page table.
Now in this scheme in case the task is already in some exit state and
that all CPU threads are frozen/kill then we can probably find a way to
do the first path mostly lock less. AFAICR nor AMD nor Intel allow to
share userptr bo hence a uptr bo should only ever be access through
ioctl submited by the process.
The second call can then be delayed and ping from time to time to see
if GPU jobs are done.
Note that what you propose might still be useful as in case there is
no buffer object for a range then OOM can make progress in freeing a
range of memory. It is very likely that significant virtual address
range of a process and backing memory can be reclaim that way. This
assume OOM reclaim vma by vma or in some form of granularity like
reclaiming 1GB by 1GB. Or we could also update blocking callback to
return range that are blocking that way OOM can reclaim around.
Cheers,
Jérôme
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
[Hmm, the cc list got mangled somehow - you have just made many people
to work for suse ;) and to kvack.org in the preious one - fixed up
hopefully]
On Fri 22-06-18 17:07:21, Chris Wilson wrote:
> Quoting Michal Hocko (2018-06-22 16:57:16)
> > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > Quoting Michal Hocko (2018-06-22 16:02:42)
> > > > Hi,
> > > > this is an RFC and not tested at all. I am not very familiar with the
> > > > mmu notifiers semantics very much so this is a crude attempt to achieve
> > > > what I need basically. It might be completely wrong but I would like
> > > > to discuss what would be a better way if that is the case.
> > > >
> > > > get_maintainers gave me quite large list of people to CC so I had to
> > > > trim
> > > > it down. If you think I have forgot somebody, please let me know
> > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > index 854bd51b9478..5285df9331fa 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object *mo)
> > > > mo->attached = false;
> > > > }
> > > >
> > > > -static void i915_gem_userptr_mn_invalidate_range_start(struct
> > > > mmu_notifier *_mn,
> > > > +static int i915_gem_userptr_mn_invalidate_range_start(struct
> > > > mmu_notifier *_mn,
> > > >struct mm_struct
> > > > *mm,
> > > >unsigned long
> > > > start,
> > > > - unsigned long
> > > > end)
> > > > + unsigned long
> > > > end,
> > > > + bool blockable)
> > > > {
> > > > struct i915_mmu_notifier *mn =
> > > > container_of(_mn, struct i915_mmu_notifier, mn);
> > > > @@ -124,7 +125,7 @@ static void
> > > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > > LIST_HEAD(cancelled);
> > > >
> > > > if (RB_EMPTY_ROOT(&mn->objects.rb_root))
> > > > - return;
> > > > + return 0;
> > >
> > > The principle wait here is for the HW (even after fixing all the locks
> > > to be not so coarse, we still have to wait for the HW to finish its
> > > access).
> >
> > Is this wait bound or it can take basically arbitrary amount of time?
>
> Arbitrary. It waits for the last operation in the queue that needs that
> set of backing pages, and that queue is unbounded and not even confined
> to the local driver. (Though each operation should be bounded to be
> completed within an interval or be cancelled, that interval is on the
> order of 10s!)
OK, I see. We should rather not wait that long so backoff is just
better. The whole point of the oom_reaper is to tear down and free some
memory. We do not really need to reclaim all of it.
It would be great if we could do something like - kick the tear down of
the device memory but have it done in the background. We wouldn't tear
the vma down in that case but the whole process would start at least.
I am not sure something like that is possible.
> > > The first pass would be then to not do anything here if
> > > !blockable.
> >
> > something like this? (incremental diff)
>
> Yup.
Cool, I will start with that because even that is an improvement from
the oom_reaper POV.
Thanks!
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
[Resnding with the CC list fixed]
On Fri 22-06-18 18:40:26, Michal Hocko wrote:
> On Fri 22-06-18 12:18:46, Jerome Glisse wrote:
> > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> > > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > > Quoting Michal Hocko (2018-06-22 16:02:42)
> > > > > Hi,
> > > > > this is an RFC and not tested at all. I am not very familiar with the
> > > > > mmu notifiers semantics very much so this is a crude attempt to
> > > > > achieve
> > > > > what I need basically. It might be completely wrong but I would like
> > > > > to discuss what would be a better way if that is the case.
> > > > >
> > > > > get_maintainers gave me quite large list of people to CC so I had to
> > > > > trim
> > > > > it down. If you think I have forgot somebody, please let me know
> > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > index 854bd51b9478..5285df9331fa 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object
> > > > > *mo)
> > > > > mo->attached = false;
> > > > > }
> > > > >
> > > > > -static void i915_gem_userptr_mn_invalidate_range_start(struct
> > > > > mmu_notifier *_mn,
> > > > > +static int i915_gem_userptr_mn_invalidate_range_start(struct
> > > > > mmu_notifier *_mn,
> > > > >struct
> > > > > mm_struct *mm,
> > > > >unsigned long
> > > > > start,
> > > > > - unsigned long
> > > > > end)
> > > > > + unsigned long
> > > > > end,
> > > > > + bool blockable)
> > > > > {
> > > > > struct i915_mmu_notifier *mn =
> > > > > container_of(_mn, struct i915_mmu_notifier, mn);
> > > > > @@ -124,7 +125,7 @@ static void
> > > > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > > > LIST_HEAD(cancelled);
> > > > >
> > > > > if (RB_EMPTY_ROOT(&mn->objects.rb_root))
> > > > > - return;
> > > > > + return 0;
> > > >
> > > > The principle wait here is for the HW (even after fixing all the locks
> > > > to be not so coarse, we still have to wait for the HW to finish its
> > > > access).
> > >
> > > Is this wait bound or it can take basically arbitrary amount of time?
> >
> > Arbitrary amount of time but in desktop use case you can assume that
> > it should never go above 16ms for a 60frame per second rendering of
> > your desktop (in GPU compute case this kind of assumption does not
> > hold). Is the process exit_state already updated by the time this mmu
> > notifier callbacks happen ?
>
> What do you mean? The process is killed (by SIGKILL) at the time but we
> do not know much more than that. The task might be stuck anywhere in the
> kernel before handling that signal.
>
> > > > The first pass would be then to not do anything here if
> > > > !blockable.
> > >
> > > something like this? (incremental diff)
> >
> > What i wanted to do with HMM and mmu notifier is split the invalidation
> > in 2 pass. First pass tell the drivers to stop/cancel pending jobs that
> > depends on the range and invalidate internal driver states (like clear
> > buffer object pages array in case of GPU but not GPU page table). While
> > the second callback would do the actual wait on the GPU to be done and
> > update the GPU page table.
>
> What can you do after the first phase? Can I unmap the range?
>
> > Now in this scheme in case the task is already in some exit state and
> > that all CPU threads are frozen/kill then we can probably find a way to
> > do the first path mostly lock less. AFAICR nor AMD nor Intel allow to
> > share userptr bo hence a uptr bo should only ever be access through
> > ioctl submited by the process.
> >
> > The second call can then be delayed and ping from time to time to see
> > if GPU jobs are done.
> >
> >
> > Note that what you propose might still be useful as in case there is
> > no buffer object for a range then OOM can make progress in freeing a
> > range of memory. It is very likely that significant virtual address
> > range of a process and backing memory can be reclaim that way. This
> > assume OOM reclaim vma by vma or in some form of granularity like
> > reclaiming 1GB by 1GB. Or we could also update blocking callback to
> > return range that are blocking that way OOM can reclaim around.
>
> Exactly my point. What we have right now is all or nothing which is
> obviously too coarse to be useful.
--
Michal Hocko
SUSE Labs
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailma
Re: [Xen-devel] [PATCH V2 2/2] x86/altp2m: Fixed domain crash with INVALID_ALTP2M EPTP index
On 06/22/2018 06:28 PM, Jan Beulich wrote:
On 13.06.18 at 10:52, wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3592,7 +3592,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>> }
>> }
>>
>> -if ( idx != vcpu_altp2m(v).p2midx )
>> +if ( idx != INVALID_ALTP2M && idx != vcpu_altp2m(v).p2midx )
>> {
>> BUG_ON(idx >= MAX_ALTP2M);
>
> In the code immediately ahead of this there is an INVALID_ALTP2M check
> already (in the else branch). If the __vmread() can legitimately produce
> this value, why would the domain be crashed when getting back
> INVALID_ALTP2M in the other case? I think the correctness of your change
> can only be judged once both code paths behave consistently.
You're right, I had somehow convinced myself that this is a #VE-specific
problem, but it looks like a generic altp2m problem. I'll simulate the
other branch in the code and see what it does with my small test
application.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Fri, Jun 22, 2018 at 06:42:43PM +0200, Michal Hocko wrote:
> [Resnding with the CC list fixed]
>
> On Fri 22-06-18 18:40:26, Michal Hocko wrote:
> > On Fri 22-06-18 12:18:46, Jerome Glisse wrote:
> > > On Fri, Jun 22, 2018 at 05:57:16PM +0200, Michal Hocko wrote:
> > > > On Fri 22-06-18 16:36:49, Chris Wilson wrote:
> > > > > Quoting Michal Hocko (2018-06-22 16:02:42)
> > > > > > Hi,
> > > > > > this is an RFC and not tested at all. I am not very familiar with
> > > > > > the
> > > > > > mmu notifiers semantics very much so this is a crude attempt to
> > > > > > achieve
> > > > > > what I need basically. It might be completely wrong but I would like
> > > > > > to discuss what would be a better way if that is the case.
> > > > > >
> > > > > > get_maintainers gave me quite large list of people to CC so I had
> > > > > > to trim
> > > > > > it down. If you think I have forgot somebody, please let me know
> > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > > b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > > index 854bd51b9478..5285df9331fa 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> > > > > > @@ -112,10 +112,11 @@ static void del_object(struct i915_mmu_object
> > > > > > *mo)
> > > > > > mo->attached = false;
> > > > > > }
> > > > > >
> > > > > > -static void i915_gem_userptr_mn_invalidate_range_start(struct
> > > > > > mmu_notifier *_mn,
> > > > > > +static int i915_gem_userptr_mn_invalidate_range_start(struct
> > > > > > mmu_notifier *_mn,
> > > > > >struct
> > > > > > mm_struct *mm,
> > > > > >unsigned
> > > > > > long start,
> > > > > > - unsigned
> > > > > > long end)
> > > > > > + unsigned
> > > > > > long end,
> > > > > > + bool
> > > > > > blockable)
> > > > > > {
> > > > > > struct i915_mmu_notifier *mn =
> > > > > > container_of(_mn, struct i915_mmu_notifier, mn);
> > > > > > @@ -124,7 +125,7 @@ static void
> > > > > > i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
> > > > > > LIST_HEAD(cancelled);
> > > > > >
> > > > > > if (RB_EMPTY_ROOT(&mn->objects.rb_root))
> > > > > > - return;
> > > > > > + return 0;
> > > > >
> > > > > The principle wait here is for the HW (even after fixing all the locks
> > > > > to be not so coarse, we still have to wait for the HW to finish its
> > > > > access).
> > > >
> > > > Is this wait bound or it can take basically arbitrary amount of time?
> > >
> > > Arbitrary amount of time but in desktop use case you can assume that
> > > it should never go above 16ms for a 60frame per second rendering of
> > > your desktop (in GPU compute case this kind of assumption does not
> > > hold). Is the process exit_state already updated by the time this mmu
> > > notifier callbacks happen ?
> >
> > What do you mean? The process is killed (by SIGKILL) at the time but we
> > do not know much more than that. The task might be stuck anywhere in the
> > kernel before handling that signal.
I was wondering if another thread might still be dereferencing any of
the structure concurrently with the OOM mmu notifier callback. Saddly
yes, it would be simpler if we could make such assumption.
> >
> > > > > The first pass would be then to not do anything here if
> > > > > !blockable.
> > > >
> > > > something like this? (incremental diff)
> > >
> > > What i wanted to do with HMM and mmu notifier is split the invalidation
> > > in 2 pass. First pass tell the drivers to stop/cancel pending jobs that
> > > depends on the range and invalidate internal driver states (like clear
> > > buffer object pages array in case of GPU but not GPU page table). While
> > > the second callback would do the actual wait on the GPU to be done and
> > > update the GPU page table.
> >
> > What can you do after the first phase? Can I unmap the range?
No you can't do anything but this force synchronization as any other
thread that concurrently trie to do something with those would queue
up. So it would serialize thing. Also main motivation on my side is
multi-GPU, right now multi-GPU are not that common but this is changing
quickly and what we see on high end (4, 8 or 16 GPUs per socket) is
spreading into more configurations. Here in mutli GPU case splitting
in two would avoid having to fully wait on first GPU before trying to
invaidate on second GPU, so on and so forth.
> >
> > > Now in this scheme in case the task is already in some exit state and
> > > that all CPU threads are frozen/kill then we can probably find a way to
> > > do the first path mostly lock less. AFAICR nor AMD nor Intel allow to
> > > s
[Xen-devel] [seabios baseline-only test] 74899: tolerable FAIL
This run is configured for baseline tests only. flight 74899 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74899/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail baseline untested test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail baseline untested test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail baseline untested test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail baseline untested test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail 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-xl-qemuu-win10-i386 17 guest-stop fail never pass version targeted for testing: seabios 237fd3943d18d7d1a4c44aa2402c26fa62e7c380 baseline version: seabios d1343e6863dd287ce7d4fcb5169c9cff568f9d1b Last test of basis74586 2018-04-13 03:22:28 Z 70 days Testing same since74899 2018-06-22 06:01:38 Z0 days1 attempts People who touched revisions under test: Kevin O'Connor 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 237fd3943d18d7d1a4c44aa2402c26fa62e7c380 Author: Kevin O'Connor Date: Mon Jun 11 12:05:31 2018 -0400 docs: Update Download.md to use git clone via https Signed-off-by: Kevin O'Connor ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-jessie test] 74900: tolerable FAIL
flight 74900 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74900/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 74872 baseline version: flight 74872 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-jessie-netboot-pvgrub pass test-amd64-i386-i386-jessie-netboot-pvgrub pass test-amd64-i386-amd64-jessie-netboot-pygrub pass test-armhf-armhf-armhf-jessie-netboot-pygrub fail test-amd64-amd64-i386-jessie-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 124571: all pass - PUSHED
flight 124571 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/124571/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8e586296c114f630188cfe4c76df91a1e2b7a5b2 baseline version: ovmf 855abe0204cb932c8059a573a06a59ddc714ca49 Last test of basis 124466 2018-06-20 23:11:35 Z1 days Failing since124515 2018-06-21 13:20:08 Z1 days2 attempts Testing same since 124571 2018-06-22 02:40:38 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Chris Co Christopher Co Dandan Bi Fu Siyuan Ruiyu Ni Sami Mujawar Sivaraman Nainar 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 855abe0204..8e586296c1 8e586296c114f630188cfe4c76df91a1e2b7a5b2 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf baseline-only test] 74901: all pass
This run is configured for baseline tests only. flight 74901 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74901/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8e586296c114f630188cfe4c76df91a1e2b7a5b2 baseline version: ovmf 855abe0204cb932c8059a573a06a59ddc714ca49 Last test of basis74894 2018-06-21 13:20:08 Z1 days Testing same since74901 2018-06-22 18:52:42 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Chris Co Christopher Co Dandan Bi Fu Siyuan Ruiyu Ni Sami Mujawar Sivaraman Nainar jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 8e586296c114f630188cfe4c76df91a1e2b7a5b2 Author: Chris Co Date: Fri Apr 13 23:43:27 2018 + ArmPkg/ArmMmuLib ARM: fix Mva to use idx instead of table base Mva address calculation should use the left-shifted current section index instead of the left-shifted table base address. Using the table base address here has the side-effect of potentially causing an access violation depending on the base address value. Cc: Leif Lindholm Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Christopher Co Reviewed-by: Ard Biesheuvel commit 6e275c613e15ffc6dc79901fb244e8cb20af9948 Author: Ard Biesheuvel Date: Thu Jun 21 09:17:52 2018 +0200 ArmPkg/ArmMmuLib ARM: assume page tables are in writeback cacheable memory Given that these days, our ARM port only supports ARMv7 and later, we can assume that the page table walker's memory accesses are cache coherent, and so there is no need to perform cache maintenance. It does require the page tables themselves to reside in memory mapped as writeback cacheable so ASSERT() that this is the case. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm commit 713aea34864ce5fc0a248b85bf3caa64fcf22467 Author: Ard Biesheuvel Date: Wed Jun 20 21:01:52 2018 +0200 ArmPkg/ArmMmuLib ARM: remove cache maintenance of block mapping contents Peculiarly enough, the current page table manipulation code takes it upon itself to write back and invalidate the memory contents covered by page and section mappings when their memory attributes change. It is not generally the case that data must be written back when such a change occurs, even when switching from cacheable to non-cacheable attributes, and in some cases, it is actually causing problems. (The cache maintenance is also performed on the PCIe MMIO regions as they get mapped by the PCI bus driver, and under virtualization, each cache maintenance operation on an emulated MMIO region triggers a round trip to the host and back) So let's just drop this code. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Reviewed-by: Leif Lindholm commit c2d6e2bc12b2a4e99304a1ebbc3474638721f5a8 Author: Ruiyu Ni Date: Thu Jun 14 13:55:21 2018 +0800 ShellPkg/comp: return NOT_EQUAL when compared files are different Today's implementation returns 0 even when compared files are different. The patch returns 27 (SHELL_NOT_QUAL) in such case to follow the shell spec. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni Reviewed-by: Jaben Carsey commit 2e1083038d9aa74fcaa2db8158fdee7c8b4af3bb Author: Dandan Bi Date: Tue Jun 19 15:38:47 2018 +0800 SignedCapsulePkg/SystemFirmwareUpdateDxe: Fix ECC issues Make function comments align with functions. Cc: Star Zeng Cc: Michael D Kinney Cc: Jiewen Yao
[Xen-devel] [xen-4.6-testing test] 124551: tolerable FAIL - PUSHED
flight 124551 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/124551/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 124469 pass in 124551 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 124469 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 124469 like 123907 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 123907 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123907 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123907 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123907 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 123907 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123907 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 123907 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123907 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 123907 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 123907 test-xtf-amd64-amd64-4 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-1 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-4 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-2 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-1 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-4 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-2 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-1 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-2 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-3 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-5 37 xtf/test-hvm32pae-memop-seg fail never pass test-xtf-amd64-amd64-3 52 xtf/test-hvm64-memop-seg fail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-xtf-amd64-amd64-5 52 xtf/test-hvm64-memop-seg fail never pass test-xtf-amd64-amd64-3 77 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-5 77 xtf/test-pv32pae-xsa-194 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-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-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 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-xsm 13 migrate-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-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-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 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-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-amd64-xl-qemut-ws16-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-qemut-win10-i386 10 wind
[Xen-devel] [seabios test] 124585: regressions - FAIL
flight 124585 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/124585/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 124521 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124521 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 124521 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 124521 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 124521 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-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-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass version targeted for testing: seabios d9a8b867a3af8090290b69b8f94b24e7fba9e504 baseline version: seabios 237fd3943d18d7d1a4c44aa2402c26fa62e7c380 Last test of basis 124521 2018-06-21 14:40:20 Z1 days Testing same since 124585 2018-06-22 06:10:18 Z0 days1 attempts People who touched revisions under test: Gerd Hoffmann jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt fail build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictfail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 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. commit d9a8b867a3af8090290b69b8f94b24e7fba9e504 Author: Gerd Hoffmann Date: Wed Nov 15 14:43:10 2017 +0100 qemu: add qemu ramfb support Add support for qemu ramfb. This is a simple boot framebuffer device, with normal ram being used to back the framebuffer and fw_cfg being used to configure the device. Use case (on x86): boot display for vgpu devices (which neither emulate vga nor have a vgabios). Sharing fw_cfg code with seabios turned out to be difficuilt due to various dependencies the code has on infrastructure which only seabios has. So include a copy of the code here, with those dependencies removed a
[Xen-devel] [xen-unstable test] 124566: tolerable FAIL - PUSHED
flight 124566 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/124566/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 124057 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 124057 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 124057 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 124090 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 124090 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124090 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124090 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 124090 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 124090 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 124090 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-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-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 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-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-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-armhf-armhf-xl-xsm 13 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 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-libvirt-xsm 13 migrate-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-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 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-armhf-armhf-libvirt-raw 12 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 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-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-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 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 437211cb696515ee5bd5dae0ab72866c9f382a33 baseline version: xen 11535cdbc0ae5925a55b3e735447c30faaa6f63b Last test of basis 124090 2018-06-12 01:51:41 Z 10 days Failing since124140 2018-06-12 17:06:49 Z 10 days9 attempts Testing same since 124566 2018-06-22 01:33:50 Z1 days1 attempts People who touched revisions under test: Andrew Cooper Ian Jackson
[Xen-devel] [libvirt test] 124580: regressions - FAIL
flight 124580 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/124580/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 123814 build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 123814 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a version targeted for testing: libvirt 1136fd4ebe886f9c3bd396c4488279ba22a8e5d5 baseline version: libvirt 076a2b409667dd9f716a2a2085e1ffea9d58fe8b Last test of basis 123814 2018-06-05 04:19:23 Z 17 days Failing since123840 2018-06-06 04:19:28 Z 16 days 17 attempts Testing same since 124580 2018-06-22 04:19:03 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Anya Harter Brijesh Singh Chen Hanxiao Christian Ehrhardt Cole Robinson Daniel Nicoletti Daniel P. Berrangé Erik Skultety Fabiano Fidêncio Filip Alac intrigeri intrigeri Jamie Strandboge Jiri Denemark John Ferlan Julio Faracco Ján Tomko Katerina Koukiou Laine Stump Laszlo Ersek Luyao Huang Marc Hartmayer Martin Kletzander Michal Privoznik Pavel Hrdina Peter Krempa Radostin Stoyanov Ramy Elkest ramyelkest Roman Bogorodskiy Stefan Bader Stefan Berger jobs: build-amd64-xsm pass build-arm64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-arm64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pairblocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked
[Xen-devel] Time to branch off 4.11
Ian, could you please branch off Xen 4.11 at current master (commit 437211cb696515ee5bd5dae0ab72866c9f382a33)? There has been a push, so I believe its time. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [linux-linus test] 124444: regressions - trouble: blocked/broken/fail/pass
flight 12 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/12/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-rtds broken test-armhf-armhf-xl-cubietruck broken test-armhf-armhf-libvirt-xsm broken test-armhf-armhf-xl-vhd broken test-armhf-armhf-xl-cubietruck 4 host-install(4) broken REGR. vs. 123554 test-armhf-armhf-libvirt-xsm 4 host-install(4)broken REGR. vs. 123554 test-armhf-armhf-xl-vhd 4 host-install(4)broken REGR. vs. 123554 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123554 build-i386-pvops 6 kernel-build fail REGR. vs. 123554 test-armhf-armhf-examine 8 reboot fail REGR. vs. 123554 test-armhf-armhf-libvirt-raw 7 xen-boot fail REGR. vs. 123554 test-armhf-armhf-xl 7 xen-boot fail REGR. vs. 123554 test-armhf-armhf-xl-multivcpu 7 xen-bootfail REGR. vs. 123554 test-armhf-armhf-libvirt 7 xen-boot fail REGR. vs. 123554 test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 123554 test-armhf-armhf-xl-xsm 7 xen-boot fail REGR. vs. 123554 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 4 host-install(4)broken REGR. vs. 123554 Tests which did not succeed, but are not blocking: test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123554 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123554 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 123554 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123554 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt 13 migrate-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-xsm 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 test-amd64-amd
[Xen-devel] [qemu-mainline test] 124582: regressions - FAIL
flight 124582 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/124582/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt6 libvirt-buildfail REGR. vs. 124232 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 16 depriv-audit-qemu/create/privcmd running test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 16 depriv-audit-qemu/create/privcmd running test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 17 depriv-audit-qemu/create/gntdev running test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 17 depriv-audit-qemu/create/gntdev running test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 18 depriv-audit-qemu/create/evtchn running test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 18 depriv-audit-qemu/create/evtchn running test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 19 depriv-audit-qemu/create/other running test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 19 depriv-audit-qemu/create/other running test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 20 depriv-audit-qemu/create/xenstore running test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 20 depriv-audit-qemu/create/xenstore running Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 124232 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 124232 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124232 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 124232 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 124232 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 124232 test-amd64-i386-xl-pvshim12 guest-start 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-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-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-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass 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 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 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-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 15 depriv-audit-qemu/create fail never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 15 depriv-audit-qemu/create fail 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-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 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 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 migrate-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-xl-xsm 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-xsm 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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrat
