On Fri, Feb 09, 2018 at 04:59:11PM +, Roger Pau Monné wrote:
>On Fri, Nov 17, 2017 at 02:22:16PM +0800, Chao Gao wrote:
>> Software sets SIRTP field of GCMD to set/update the interrupt remapping
>> table pointer used by hardware. The interrupt remapping table pointer is
>> specified through
Boris Ostrovsky:
> On 02/07/2018 05:22 PM, Simon Gaiser wrote:
>> +users_old = xs_state_users;
>> xs_state_users--;
>> if ((req->type == XS_TRANSACTION_START && req->msg.type == XS_ERROR) ||
>> req->type == XS_TRANSACTION_END)
>> xs_state_users--;
>> +if
flight 118771 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118771/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-amd64-xl-pvhv2-amd
flight 118784 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118784/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-xsm 5 host-ping-check-native fail in 118683 pass in 118784
On Fri, Feb 09, 2018 at 05:15:17PM +, Roger Pau Monné wrote:
>On Fri, Nov 17, 2017 at 02:22:17PM +0800, Chao Gao wrote:
>> Software writes this field to enable/disable interrupt reampping. This
>> patch emulate IRES field of GCMD. Currently, Guest's whole IRT are
>> mapped to Xen permanently
flight 118775 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 118324
On Fri, Feb 09, 2018 at 05:44:17PM +, Roger Pau Monné wrote:
>On Fri, Nov 17, 2017 at 02:22:18PM +0800, Chao Gao wrote:
>> When a remapping interrupt request arrives, remapping hardware computes the
>> interrupt_index per the algorithm described in VTD spec
>> "Interrupt Remapping Table",
(Resending too. Something was wrong with my client)
On 02/10/2018 11:33 AM, Boris Ostrovsky wrote:
On 02/08/2018 10:25 AM, Alexandru Isaila wrote:
This commit enables MSR events for svm.
Signed-off-by: Alexandru Isaila
Reviewed-by: Boris Ostrovsky
flight 118735 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118735/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 118667
test-armhf-armhf-libvirt-xsm 14
flight 118730 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118730/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-raw 9 leak-check/basis(9) fail in 118666 pass in
118730
test-amd64-amd64-rumprun-amd64
flight 118748 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118748/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 broken
test-amd64-i386-freebsd10-amd64 4
flight 118737 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which are
flight 118751 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118751/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 118670
Tests which did
On 02/08/2018 10:25 AM, Alexandru Isaila wrote:
+
+ rc = hvm_monitor_debug(regs->rip,
+ HVM_MONITOR_SOFTWARE_BREAKPOINT,
+ X86_EVENTTYPE_SW_EXCEPTION,
+ inst_len);
+ if ( rc
On 02/07/2018 05:22 PM, Simon Gaiser wrote:
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
concurrent xenstore accesses") made a subtle change to the semantic of
xenbus_dev_request_and_reply() and xenbus_transaction_end().
Before on an error response to XS_TRANSACTION_END
On 02/07/2018 05:22 PM, Simon Gaiser wrote:
As the previous commit shows it's quite easy to confuse the transaction
reference counting by ending a transaction twice. So at least try to
detect and report it.
Signed-off-by: Simon Gaiser
---
16 matches
Mail list logo