The CONTROL command (former DEBUG command) isn't specified in the
xenstore protocol doc. Add it.
Signed-off-by: Juergen Gross
---
docs/misc/xenstore.txt | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.
The endianess of the xenstore protocol header should be specified.
Signed-off-by: Juergen Gross
---
docs/misc/xenstore.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/misc/xenstore.txt b/docs/misc/xenstore.txt
index ae1b6a8c6e..5051340227 100644
--- a/docs/misc/xen
Hi Julien,
> On 28/04/17 17:01, Bhupinder Thakur wrote:
>>
>> The SBSA uart node format is as specified in
>> Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given
>> below:
>>
>> ARM SBSA defined generic UART
>> --
>> This UART uses a subset of the PL011
Hi Julien,
On 05/02/2017 02:01 PM, Julien Grall wrote:
>
>
> On 02/05/17 12:56, Julien Grall wrote:
>> Hi Sergej,
>>
>> On 30/04/17 20:48, Sergej Proskurin wrote:
>>> The TTBCR_SZ holds only 3 bits and thus must be masked with the value
>>> 0x7 instead of the previously used value 0xf.
>>
>> Plea
flight 109144 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109144/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
Hi,
>>> I was wondering whether it would be better to defer the PL011 creation to
>>> a
>>> domctl. This could be called after the domain is created with all the
>>> information required (MMIO region, Console PFN...).
>>>
>>> This would also make the migration support more trivial as the we will
>
Hi Julien,
On 05/02/2017 01:56 PM, Julien Grall wrote:
> Hi Sergej,
>
> On 30/04/17 20:48, Sergej Proskurin wrote:
>> The TTBCR_SZ holds only 3 bits and thus must be masked with the value
>> 0x7 instead of the previously used value 0xf.
>
> Please quote the spec (paragaph + version) when you do a
Hi Stefano,
On 29 April 2017 at 04:40, Stefano Stabellini wrote:
> On Fri, 28 Apr 2017, Bhupinder Thakur wrote:
>> Xenconsole supports only PV console currently. This patch adds support
>> for vuart, which allows emulated pl011 uart to be accessed as a console.
>>
>> This patch modifies different
Revert commit 72a9b186292 ("xen: Remove event channel notification
through Xen PCI platform device") as the original analysis was wrong
that all the removed code isn't in use any more. As commit da72ff5bfcb0
("partially revert xen: Remove event channel notification through Xen
PCI platform device")
On Fri, May 05, 2017 at 02:38:08PM -0500, Eric Blake wrote:
> Time to wire up all the call sites that request a shutdown or
> reset to use the enum added in the previous patch.
>
> It would have been less churn to keep the common case with no
> arguments as meaning guest-triggered, and only modifi
Hi Stefano,
>> >> >> >> > It looks like you are reusing the libxl__device_console_add call
>> >> >> >> > for the
>> >> >> >> > main PV console for the domain, to also add the vuart nodes to
>> >> >> >> > xenstore.
>> >> >> >> >
>> >> >> >> > I don't think it is a good idea to mix the two. I sugg
Revert commit 72a9b186292 ("xen: Remove event channel notification
through Xen PCI platform device") as the original analysis was wrong
that all the removed code isn't in use any more.
It is still necessary for old Xen versions (< 4.0) and for being able
to run the Linux kernel as dom0 in a nested
Revert commit 72a9b186292 ("xen: Remove event channel notification
through Xen PCI platform device") as the original analysis was wrong
that all the removed code isn't in use any more. As commit da72ff5bfcb0
("partially revert xen: Remove event channel notification through Xen
PCI platform device")
flight 109127 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109127/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 59254
test-amd64-amd64-pa
flight 109147 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109147/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d7b96017ccf5922b798f496fbcdcac4067d04c6d
baseline version:
ovmf 97cdb33b575a80ca5c20a
flight 109133 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
> From: Jan Beulich
> Sent: Friday, May 5, 2017 6:16 PM
>
> >>> On 04.05.17 at 23:30, wrote:
> > Setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results in a General
> > Protection Fault and thus results in a hypervisor crash. This behavior has
> > been observed on two generations of Intel pr
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, May 4, 2017 8:02 PM
>
> This is because that code, added by commit 997382b771 ("y86/vmx: dump
> PIR and vIRR before ASSERT()"), was meant to be removed by the time we
> finalize 4.9, but the root cause of the ASSERT() wrongly(?) trig
flight 109117 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109117/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
test-amd64-i386-xl-qe
flight 109112 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109112/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop fail REGR. vs. 107900
Tests which are fa
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemut-rhel6hvm-intel
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-tradit
Hi,
I read that only bug fixes are being accepted for qemu-xen-traditional.
I'd quite like to see SASL
support for VNC in qemu-xen-traditional so that it is available when
using IOEMU stub-domains.
I've got a patch that back-ports this support from upstream QEMU but as
it can't be considere
flight 109119 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109119/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
flight 109105 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109105/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 59254
test-amd64-i386-qem
Just wanted to quickly clarify since I don't see it mentioned anywhere
in the docs. The XenStore protocol doesn't seem to define endianness
anywhere (it matters for the header). In practice its little endian
since that's where its running but I was hoping someone could
conclusively nail it down.
T
flight 109108 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109108/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
flight 109095 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109095/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
test-amd64-i386-xl-qe
flight 109115 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109115/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 8839be5c1fe339a1310b4e05e88c5a0230b7959d
baseline version:
xen ba10
flight 109091 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109091/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop fail REGR. vs. 107900
Tests which are fa
This run is configured for baseline tests only.
flight 71261 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71261/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 3 ho
30 matches
Mail list logo
