On Fri, Jun 16, 2017 at 09:52:11AM -0600, Jan Beulich wrote:
On 16.06.17 at 08:48, wrote:
>> The problem is a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
>> we would wrongly use 00:00.0 to search VT-d unit.
>>
>> To search VT-d unit for a VF, the BDF of the PF is used. And If the
>> P
flight 110547 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110547/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 110515
test-amd64-amd64-xl
Hi,
when I try to attach a pci device to a running HVM the interrupt setup
inside the domain fails if the Linux has PV support:
kernel: xen:events: Failed to obtain physical IRQ 36
When I use [0] to get a more verbose output I get
kernel: xen:events: Failed to obtain physical IRQ 36 (error
Hi,
I'm currently debugging why hotplugging pci devices doesn't work with the
linux based stubdom used in the next Qubes release (based on Anthony's
and Eric's patches).
When attaching a pci device to a running domain qemu in the stubdom
throws the following error:
[00:06.0] xen_pt_region_upda
flight 110545 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110545/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
110456
Tests which ar
flight 110544 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110544/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 5 xen-build fail in 110510 REGR. vs. 110465
Tests which are fa
flight 110542 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110542/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 4 host-build-prep fail in 110499 REGR. vs. 110417
Tests which are
This run is configured for baseline tests only.
flight 71583 linux-3.10 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71583/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops
On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper wrote:
> On 04/04/17 14:14, Jan Beulich wrote:
>> We shouldn't hand MFN info back from increase-reservation for
>> translated domains, just like we don't for populate-physmap and
>> memory-exchange. For full symmetry also check for a NULL guest handle
flight 110537 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110537/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 110516
pass in 110537
test-amd64-i386-xl-
flight 110536 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110536/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 6 reboot fail REGR. vs. 110515
build-i386-pvops
flight 110535 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110535/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
110456
Tests which ar
flight 110533 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110533/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 5 xen-build fail in 110510 REGR. vs. 110465
Tests which are fa
flight 110543 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110543/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 7251b0d2b28552bf8d7287af9dc2504b4a43278b
baseline version:
xen b6e5
On Sun, 2017-06-18 at 00:13 -0700, Christoph Hellwig wrote:
> On Sun, Jun 18, 2017 at 06:50:27AM +1000, Benjamin Herrenschmidt wrote:
> > What is your rationale here ? (I have missed patch 0 it seems).
>
> Less code duplication, more modular dma_map_ops insteance.
>
> > dma_supported() was suppos
flight 110524 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110524/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 4 host-build-prep fail in 110499 REGR. vs. 110417
Tests which are
On Sun, Jun 18, 2017 at 06:50:27AM +1000, Benjamin Herrenschmidt wrote:
> What is your rationale here ? (I have missed patch 0 it seems).
Less code duplication, more modular dma_map_ops insteance.
> dma_supported() was supposed to be pretty much a "const" function
> simply informing whether a giv
On Fri, Jun 16, 2017 at 01:40:24PM -0700, Alexander Duyck wrote:
> dma_unmap_page on dest_dma if "op == IOAT_OP_XOR"? Odds are it is what
> the compiler is already generating and will save a few lines of code
> so what you end up with is something like:
Honestly wanted to touch the code as little
18 matches
Mail list logo
