flight 173121 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 173123 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173123/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
flight 173130 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173130/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 173128 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173128/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 173126 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173126/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-qemut-rhel6hvm-amd 7 xen-install fail in 173116 pass in 173126
test-amd64-i386-migrupgrade 10
flight 173134 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173134/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 173129 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
flight 173135 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173135/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 173131 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173131/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 173137 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173137/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 173133 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 172133
build-i386-libvirt
flight 173136 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173136/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
flight 173140 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Prior to this commit, if a grant mapping operation failed partially,
some of the entries in the map_ops array would be invalid, whereas all
of the entries in the kmap_ops array would be valid. This in turn would
cause the following logic in gntdev_map_grant_pages to become invalid:
for (i = 0; i
Prior to this commit, the gntdev driver code did not handle the
following scenario correctly:
* User process sets up a gntdev mapping composed of two grant mappings
(i.e., two pages shared by another Xen domain).
* User process munmap()s one of the pages.
* User process munmap()s the remaining p
Hi all,
The changes in this patch series intend to fix the Xen grant device
driver, so that grant mapping leaks caused by partially failed grant
mapping operations are avoided with the first patch, and so that the
splitting of VMAs does not result in incorrectly unmapped grant pages
with the secon
flight 173138 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173138/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 173143 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173143/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
While looking at the grant table code I thought it should be possible
to have a smaller struct active_grant_entry. This approach should only
hit transitive grants with some negative performance effect, "normal"
grants should be not affected.
I'm not sure that the domid_to_domain() helper is someth
Add a helper domid_to_domain() returning the struct domain pointer for
a domain give by its domid and which is known not being able to be
released (its reference count isn't incremented and no rcu_lock_domain()
is called for it).
In order to simplify coding add an internal helper for doing the loo
The size of struct active_grant_entry for 64-bit builds is 40 or 48
bytes today (with or without NDEBUG).
It can easily be reduced by 8 bytes by replacing the trans_domain
pointer with the domid of the related domain. trans_domain is only ever
used for transitive grants, which last known user has
On 09.09.2022 17:41, Daniel P. Smith wrote:
>
> On 9/9/22 08:10, Jan Beulich wrote:
>> On 09.09.2022 13:34, Daniel P. Smith wrote:
>>> On 9/9/22 06:04, Jan Beulich wrote:
On 09.09.2022 11:50, Daniel P. Smith wrote:
> --- a/xen/xsm/flask/avc.c
> +++ b/xen/xsm/flask/avc.c
> @@ -566,
Having cppcheck-misra.json depend on cppcheck-misra.txt does not
properly address the multiple targets problem. If cppcheck-misra.json
is deleted from the build tree but cppcheck-misra.txt is still there,
nothing will re-generate cppcheck-misra.json.
With GNU make 4.3 or newer we could use the &:
23 matches
Mail list logo