flight 122014 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 121876
build-amd64
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
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
flight 122003 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122003/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 121876
build-amd64
flight 121977 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121977/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 121769
build-amd64-xsm
flight 121946 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121946/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 121771
test-armhf-armhf-libvirt 14 saveresto
flight 121997 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121997/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 121876
build-amd64
This run is configured for baseline tests only.
flight 74550 qemu-upstream-4.10-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74550/
Failures and problems with tests :-(
Tests which did not succeed,
including tests which could not be run:
test-armhf-armhf-xl-midway
flight 121895 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121895/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 120095
test-amd64-amd64-
flight 121990 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121990/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 121876
build-amd64
On Fri, Apr 06, 2018 at 06:12:50PM +0100, Wei Liu wrote:
> On Fri, Apr 06, 2018 at 05:32:57PM +0200, Marek Marczykowski-Górecki wrote:
> > "#pragma GCC diagnostic push" is supported only on gcc >= 4.6. But since
> > muting this the warning is needed only on gcc >= 8, do it only then,
> > instead of
flight 121949 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121949/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
119227
Tests w
This run is configured for baseline tests only.
flight 74554 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74554/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aae02dccf5b0ad07e60d2738f350b3b39df389d7
baseline v
This run is configured for baseline tests only.
flight 74549 xen-4.10-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74549/
Failures and problems with tests :-(
Tests which did not succeed,
including tests which could not be run:
test-armhf-armhf-xl-midway1 build-c
On 06/04/2018 22:54, Doug Goldstein wrote:
> It looks like GitLab still hasn't been approved by moderators to post to
> the ML so I'm doing this manually.
>
> Staging is broken after 115fb8e3 to 33fcfac4 based on the GitLab run at
> https://gitlab.com/xen-project/xen/pipelines/20103399 I believe it
It looks like GitLab still hasn't been approved by moderators to post to
the ML so I'm doing this manually.
Staging is broken after 115fb8e3 to 33fcfac4 based on the GitLab run at
https://gitlab.com/xen-project/xen/pipelines/20103399 I believe it is
f46b6197344fca91db7e1d7bd6df0c4a2703ed6f based o
This run is configured for baseline tests only.
flight 74551 linux-arm-xen real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74551/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64
Commit 99605175c (xen-pt: Fix PCI devices re-attach failed) introduced
a subtle bug. As soon as the guest switches off Bus Mastering on the
device it immediately causes all the BARs be unmapped due to the DMA
address space of the device being changed. This is undesired behavior
because the guest ma
flight 121963 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121963/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754
build-i386-rumprun
On Fri, 6 Apr 2018, Artem Mygaiev wrote:
> > > > 2) Create a subset of functions that need to go through certifications
> > > > Next step: create a small Kconfig. We could use the Renesas Rcar as
> > > > reference. We need a discussion about the features we need, for
> > > > example real-time sched
flight 121986 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121986/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 121876
build-amd64
flight 121848 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121848/
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-libvirt-xsm 13
flight 121842 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121842/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324
test-amd64-i386-xl-
flight 121951 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121951/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf ffb046f213f3e36f6f3cc9467298c3ebc8b3ac9f
baseline version:
xtf e8debcece867acffc2c0c4
Drop the _mfn() wrappers now that page_to_mfn() returns the correct type.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Julien Grall
CC: Paul Durrant
CC: Juergen Gross
---
xen/arch/x86/hvm/ioreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen
Hi Jarvis
On 06.04.18 20:01, Jarvis Roach wrote:
Hi all,
adding a few more people who are/may be interested in safety certification,
including committers (because item 1 would have an impact). Specifically:
Rich Persaud, Paul Luperto, Jonathan Daugherty and Denys Balatsko.
There are a few loos
On 06/04/18 08:52, Juergen Gross wrote:
> Avoid flushing the complete TLB when switching %cr3 for mitigation of
> Meltdown by using the PCID feature if available.
>
> We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
> 2 values for the non-XPTI case:
>
> - guest active and in ke
Jarvis,
thanks for the valuable input.
On 06/04/2018, 19:01, "Jarvis Roach" wrote:
>
> Here my understanding is that we need a certification partner like TÜV,
> MIRA or a company like Dornerworks who already have experience with
> Xen. By working with a partner experienced in
flight 121982 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121982/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 121876
build-armhf
On 06.04.18 17:13, Lars Kurth wrote:
Hi all,
adding a few more people who are/may be interested in safety certification,
including committers (because item 1 would have an impact). Specifically: Rich
Persaud, Paul Luperto, Jonathan Daugherty and Denys Balatsko.
There are a few loose ends an
On Fri, Apr 06, 2018 at 05:32:57PM +0200, Marek Marczykowski-Górecki wrote:
> "#pragma GCC diagnostic push" is supported only on gcc >= 4.6. But since
> muting this the warning is needed only on gcc >= 8, do it only then,
> instead of tricking the compiler about this code (and making it less
> read
Hi,
At 16:32 +0200 on 06 Apr (1523032362), Marek Marczykowski-Górecki wrote:
> On Fri, Apr 06, 2018 at 09:56:05AM -0400, Boris Ostrovsky wrote:
> > Can we instead pre-compute the pointer to pacify the compiler? I haven't
> > seen the original error so I can't test it, but something like
>
> Nope,
> Hi all,
>
> adding a few more people who are/may be interested in safety certification,
> including committers (because item 1 would have an impact). Specifically:
> Rich Persaud, Paul Luperto, Jonathan Daugherty and Denys Balatsko.
>
> There are a few loose ends and updates from other/similar
On 06/04/18 11:40, Andrew Cooper wrote:
> On 06/04/18 10:36, Wei Liu wrote:
>> Signed-off-by: Wei Liu
>
> Acked-by: Andrew Cooper
>
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xe
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-armhf
testid xen-build
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: 74
On 04/06/2018 05:00 PM, Amit Singh Tomar wrote:
This patch adds driver for UART controller found on Armada 3700 SoC.
There is no reference manuals available for 3700 SoC in public and it
is derived by looking at Linux driver[1].
[1]https://github.com/torvalds/linux/blob/master/drivers/tty/ser
Hi,
On 06/04/18 17:00, Amit Singh Tomar wrote:
> This patch adds driver for UART controller found on Armada 3700 SoC.
>
> There is no reference manuals available for 3700 SoC in public and it
> is derived by looking at Linux driver[1].
>
> [1]https://github.com/torvalds/linux/blob/master/drivers
This patch adds driver for UART controller found on Armada 3700 SoC.
There is no reference manuals available for 3700 SoC in public and it
is derived by looking at Linux driver[1].
[1]https://github.com/torvalds/linux/blob/master/drivers/tty/serial/mvebu-uart.c
commit-id: c685af1108d7c303f0b90141
"#pragma GCC diagnostic push" is supported only on gcc >= 4.6. But since
muting this the warning is needed only on gcc >= 8, do it only then,
instead of tricking the compiler about this code (and making it less
readable to the human too).
This fixes 5888eecca0 "tools/kdd: mute spurious gcc warning
On 06/04/18 17:17, Andrew Cooper wrote:
> On 06/04/18 08:52, Juergen Gross wrote:
>> Instead of flushing the TLB from global pages when switching address
>> spaces with XPTI being active just disable global pages via %cr4
>> completely when a domain subject to XPTI is active. This avoids the
>> nee
Updated: see https://xenproject.org/help/contribution-guidelines.html
The text now is
Code Security Scanning
The Xen Project is registered with the "Coverity Scan" service which applies
Coverity's static analyser to the Open Source projects. The tool can and does
find flaws in the source code w
On 06/04/18 08:52, Juergen Gross wrote:
> Instead of flushing the TLB from global pages when switching address
> spaces with XPTI being active just disable global pages via %cr4
> completely when a domain subject to XPTI is active. This avoids the
> need for extra TLB flushes as loading %cr3 will r
On 06/04/18 16:10, Boris Ostrovsky wrote:
> On 04/06/2018 09:33 AM, George Dunlap wrote:
>> On Fri, Apr 6, 2018 at 2:12 PM, Juergen Gross wrote:
>>>
>>> So its time for a new XENFEAT_ value then? This would be the least
>>> intrusive way to add such a flag. Something like
>>> XENFEAT_linux_high_rs
On Fri, Apr 06, 2018 at 04:32:42PM +0200, Marek Marczykowski-Górecki wrote:
> > >> cc1: warnings being treated as errors
> > >> kdd.c:639: error: expected [error|warning|ignored] after ‘#pragma GCC
> > >> diagnostic’
> > >> kdd.c:714: error: expected [error|warning|ignored] after ‘#pragma GCC
> > >
flight 121978 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121978/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 121876
build-armhf
On Fri, Apr 06, 2018 at 09:56:05AM -0400, Boris Ostrovsky wrote:
> On 04/06/2018 09:41 AM, Wei Liu wrote:
> > On Fri, Apr 06, 2018 at 09:39:50AM -0400, Boris Ostrovsky wrote:
> >> On 04/06/2018 09:07 AM, Wei Liu wrote:
> >>> On Fri, Apr 06, 2018 at 08:39:53AM -0400, Boris Ostrovsky wrote:
> On
Hi all,
adding a few more people who are/may be interested in safety certification,
including committers (because item 1 would have an impact). Specifically: Rich
Persaud, Paul Luperto, Jonathan Daugherty and Denys Balatsko.
There are a few loose ends and updates from other/similar related thre
On 04/06/2018 09:33 AM, George Dunlap wrote:
> On Fri, Apr 6, 2018 at 2:12 PM, Juergen Gross wrote:
>>
>> So its time for a new XENFEAT_ value then? This would be the least
>> intrusive way to add such a flag. Something like
>> XENFEAT_linux_high_rsdp_address_okay ?
> That sounds reasonable to me.
On 04/06/2018 09:41 AM, Wei Liu wrote:
> On Fri, Apr 06, 2018 at 09:39:50AM -0400, Boris Ostrovsky wrote:
>> On 04/06/2018 09:07 AM, Wei Liu wrote:
>>> On Fri, Apr 06, 2018 at 08:39:53AM -0400, Boris Ostrovsky wrote:
On 04/04/2018 09:50 PM, Marek Marczykowski-Górecki wrote:
> gcc-8 complai
On 06/04/18 15:40, Andrew Cooper wrote:
> On 06/04/18 08:52, Juergen Gross wrote:
>> If possible use the INVPCID instruction for flushing the TLB instead of
>> toggling cr4.pge for that purpose.
>>
>> While at it remove the dependency on cr4.pge being required for mtrr
>> loading, as this will be r
On Fri, Apr 06, 2018 at 09:39:50AM -0400, Boris Ostrovsky wrote:
> On 04/06/2018 09:07 AM, Wei Liu wrote:
> > On Fri, Apr 06, 2018 at 08:39:53AM -0400, Boris Ostrovsky wrote:
> >> On 04/04/2018 09:50 PM, Marek Marczykowski-Górecki wrote:
> >>> gcc-8 complains:
> >>>
> >>> kdd.c:698:13: error: '
On 06/04/18 08:52, Juergen Gross wrote:
> If possible use the INVPCID instruction for flushing the TLB instead of
> toggling cr4.pge for that purpose.
>
> While at it remove the dependency on cr4.pge being required for mtrr
> loading, as this will be required later anyway.
>
> Add a command line op
On 04/06/2018 09:07 AM, Wei Liu wrote:
> On Fri, Apr 06, 2018 at 08:39:53AM -0400, Boris Ostrovsky wrote:
>> On 04/04/2018 09:50 PM, Marek Marczykowski-Górecki wrote:
>>> gcc-8 complains:
>>>
>>> kdd.c:698:13: error: 'memcpy' offset [-204, -717] is out of the bounds
>>> [0, 216] of object 'ctr
On Thu, Apr 05, 2018 at 02:09:11PM +0200, Juergen Gross wrote:
> Commit 4a5733771e6f33918eba07b584e564a67ac1 ("libxl: put RSDP for
> PVH guest near 4GB") broke PVH guests with Linux kernels before 4.17
> as those kernels are not taking the RSDP address from the PVH
> start_info structure, but a
On 06/04/18 15:16, Andrew Cooper wrote:
> On 06/04/18 08:52, Juergen Gross wrote:
>> Instead of switching XPTI globally on or off add a per-domain flag for
>> that purpose. This allows to modify the xpti boot parameter to support
>> running dom0 without Meltdown mitigations. Using "xpti=nodom0" as
On Fri, Apr 6, 2018 at 2:12 PM, Juergen Gross wrote:
> On 06/04/18 13:13, George Dunlap wrote:
>> On Fri, Apr 6, 2018 at 11:57 AM, Juergen Gross wrote:
>>> On 06/04/18 12:07, George Dunlap wrote:
On Fri, Apr 6, 2018 at 11:02 AM, Juergen Gross wrote:
> On 06/04/18 11:49, George Dunlap wr
On 06/04/18 08:52, Juergen Gross wrote:
> Instead of switching XPTI globally on or off add a per-domain flag for
> that purpose. This allows to modify the xpti boot parameter to support
> running dom0 without Meltdown mitigations. Using "xpti=nodom0" as boot
> parameter will achieve that.
>
> Move
On 06/04/18 13:13, George Dunlap wrote:
> On Fri, Apr 6, 2018 at 11:57 AM, Juergen Gross wrote:
>> On 06/04/18 12:07, George Dunlap wrote:
>>> On Fri, Apr 6, 2018 at 11:02 AM, Juergen Gross wrote:
On 06/04/18 11:49, George Dunlap wrote:
> On Thu, Apr 5, 2018 at 7:33 PM, Boris Ostrovsky
>
On Fri, Apr 06, 2018 at 08:39:53AM -0400, Boris Ostrovsky wrote:
> On 04/04/2018 09:50 PM, Marek Marczykowski-Górecki wrote:
> > gcc-8 complains:
> >
> > kdd.c:698:13: error: 'memcpy' offset [-204, -717] is out of the bounds
> > [0, 216] of object 'ctrl' with type 'kdd_ctrl' {aka 'union '}
>
flight 121971 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121971/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 121876
build-armhf
On 04/04/2018 09:50 PM, Marek Marczykowski-Górecki wrote:
> gcc-8 complains:
>
> kdd.c:698:13: error: 'memcpy' offset [-204, -717] is out of the bounds
> [0, 216] of object 'ctrl' with type 'kdd_ctrl' {aka 'union '}
> [-Werror=array-bounds]
> memcpy(buf, ((uint8_t *)&ctrl.c32
flight 121901 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121901/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 121769
build-amd64-xsm
flight 121814 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121814/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs.
121272
Tests which
On 06/04/18 13:21, Andrew Cooper wrote:
> On 06/04/18 08:52, Juergen Gross wrote:
>> When switching to a 64-bit pv context the TLB is flushed twice today:
>> the first time when switching to the new address space in
>> write_ptbase(), the second time when switching to guest mode in
>> restore_to_gu
On 04/03/2018 12:47 PM, Daniel Vetter wrote:
On Thu, Mar 29, 2018 at 04:19:31PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
+static int to_refs_grant_foreign_access(struct xen_gem_object *xen_obj)
+{
+ grant_ref_t priv_gref_head;
+ int ret, j, cur_ref, num_pa
On 06/04/18 08:52, Juergen Gross wrote:
> When switching to a 64-bit pv context the TLB is flushed twice today:
> the first time when switching to the new address space in
> write_ptbase(), the second time when switching to guest mode in
> restore_to_guest.
>
> Limit the first flush to non-global e
On Fri, Apr 6, 2018 at 11:57 AM, Juergen Gross wrote:
> On 06/04/18 12:07, George Dunlap wrote:
>> On Fri, Apr 6, 2018 at 11:02 AM, Juergen Gross wrote:
>>> On 06/04/18 11:49, George Dunlap wrote:
On Thu, Apr 5, 2018 at 7:33 PM, Boris Ostrovsky
wrote:
> On 04/05/2018 01:11 PM, Juer
On 06/04/18 08:52, Juergen Gross wrote:
> For mitigation of Meltdown the current L4 page table is copied to the
> cpu local root page table each time a 64 bit pv guest is entered.
>
> Copying can be avoided in cases where the guest L4 page table hasn't
> been modified while running the hypervisor,
This run is configured for baseline tests only.
flight 74492 xen-unstable running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74492/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
This run is configured for baseline tests only.
flight 74493 qemu-mainline running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74493/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On 06/04/18 12:07, George Dunlap wrote:
> On Fri, Apr 6, 2018 at 11:02 AM, Juergen Gross wrote:
>> On 06/04/18 11:49, George Dunlap wrote:
>>> On Thu, Apr 5, 2018 at 7:33 PM, Boris Ostrovsky
>>> wrote:
On 04/05/2018 01:11 PM, Juergen Gross wrote:
> On 05/04/18 16:56, George Dunlap wrote:
This run is configured for baseline tests only.
flight 74529 ovmf running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74529/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm
flight 74540 distros-debian-jessie running [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74540/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-
On 06/04/18 12:13, George Dunlap wrote:
> On Thu, Apr 5, 2018 at 6:11 PM, Juergen Gross wrote:
>>> Option 1: Put the RSDP in lowmem unless we know the guest will use the
>>> address in start_info
>>> Pro: Existing Linux instances boot
>>> Con: Existing BSD instances whose memory is an exact multip
Dear community members,
this is a quick reminder that the CfP for the Developer Summit closes in a
week. I may be able to give a few days extension, but would need to know
upfront.
More information is available at
https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg01722.html
Best
On 04/03/2018 02:22 PM, Roger Pau Monné wrote:
On Mon, Apr 02, 2018 at 01:42:32PM -0400, Konrad Rzeszutek Wilk wrote:
From: Bob Liu
The current VBD layer reserves buffer space for each attached device based on
three statically configured settings which are read at boot time.
* max_indirect_s
On Thu, Apr 5, 2018 at 6:11 PM, Juergen Gross wrote:
>> Option 1: Put the RSDP in lowmem unless we know the guest will use the
>> address in start_info
>> Pro: Existing Linux instances boot
>> Con: Existing BSD instances whose memory is an exact multiple of 1 GiB
>> will have slightly slower TLB m
On Fri, Apr 6, 2018 at 11:02 AM, Juergen Gross wrote:
> On 06/04/18 11:49, George Dunlap wrote:
>> On Thu, Apr 5, 2018 at 7:33 PM, Boris Ostrovsky
>> wrote:
>>> On 04/05/2018 01:11 PM, Juergen Gross wrote:
On 05/04/18 16:56, George Dunlap wrote:
> On Thu, Apr 5, 2018 at 3:09 PM, Juergen
On 06/04/18 11:49, George Dunlap wrote:
> On Thu, Apr 5, 2018 at 7:33 PM, Boris Ostrovsky
> wrote:
>> On 04/05/2018 01:11 PM, Juergen Gross wrote:
>>> On 05/04/18 16:56, George Dunlap wrote:
On Thu, Apr 5, 2018 at 3:09 PM, Juergen Gross wrote:
> On 05/04/18 15:42, George Dunlap wrote:
>>
On Thu, Apr 5, 2018 at 7:33 PM, Boris Ostrovsky
wrote:
> On 04/05/2018 01:11 PM, Juergen Gross wrote:
>> On 05/04/18 16:56, George Dunlap wrote:
>>> On Thu, Apr 5, 2018 at 3:09 PM, Juergen Gross wrote:
On 05/04/18 15:42, George Dunlap wrote:
> On Thu, Apr 5, 2018 at 2:06 PM, Juergen Gros
On Fri, Apr 06, 2018 at 10:40:23AM +0100, Andrew Cooper wrote:
> On 06/04/18 10:36, Wei Liu wrote:
> > Signed-off-by: Wei Liu
>
> For what purpose? This is very deliberate that, if faulting is
> available, levelling never gets touched.
>
> Levelling, as a mechanism, is strictly inferior to faul
This run is configured for baseline tests only.
flight 74485 linux-4.1 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74485/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On 06/04/18 10:36, Wei Liu wrote:
> Signed-off-by: Wei Liu
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 06/04/18 10:36, Wei Liu wrote:
> Signed-off-by: Wei Liu
For what purpose? This is very deliberate that, if faulting is
available, levelling never gets touched.
Levelling, as a mechanism, is strictly inferior to faulting. On Intel,
the sets of hardware with levelling and faulting are disjoin
On 04/06/2018 10:26 AM, Julien Grall wrote:
(+Juergen)
Hi,
On 04/05/2018 11:16 AM, Amit Singh Tomar wrote:
This patch adds driver for UART controller found on Armada 3700 SoC.
There is no reference manuals available for 3700 SoC in public and it
is derived by looking at Linux driver[1].
[1
On Fri, Apr 6, 2018 at 9:00 AM, Juergen Gross wrote:
> On 05/04/18 20:33, Boris Ostrovsky wrote:
>> On 04/05/2018 01:11 PM, Juergen Gross wrote:
>>> On 05/04/18 16:56, George Dunlap wrote:
On Thu, Apr 5, 2018 at 3:09 PM, Juergen Gross wrote:
> On 05/04/18 15:42, George Dunlap wrote:
Signed-off-by: Wei Liu
---
xen/arch/x86/setup.c | 2 +-
xen/arch/x86/smpboot.c | 2 +-
xen/include/xen/smp.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index c0b97a748a..49cf963d7a 100644
--- a/xen/arch/x86/setup.c
+++ b/x
Signed-off-by: Wei Liu
---
xen/arch/x86/cpu/amd.c | 9 +
xen/arch/x86/cpu/intel.c | 9 +
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index fc9677f020..6e3d0ae2b0 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arc
Wei Liu (2):
x86/cpu: get more information out from *_init_levelling
x86: remove unused parameter from smp_prepare_cpus
xen/arch/x86/cpu/amd.c | 9 +
xen/arch/x86/cpu/intel.c | 9 +
xen/arch/x86/setup.c | 2 +-
xen/arch/x86/smpboot.c | 2 +-
xen/include/xen/smp.h|
On Fri, Apr 06, 2018 at 10:03:14AM +0100, Julien Grall wrote:
> This is wrong. gicv_to_string works on XEN_DOMCTL_* define and not the
> LIBXL_GIC_*.
> So this will not give the right output.
>
> I would suggest to revert that patch and I will send one that actually fix
> the compilation.
> Not
Hi,
On 04/05/2018 11:16 AM, Amit Singh Tomar wrote:
This patch adds driver for UART controller found on Armada 3700 SoC.
There is no reference manuals available for 3700 SoC in public and it
is derived by looking at Linux driver[1].
[1]https://github.com/torvalds/linux/blob/master/drivers/tty/
Hi,
On 04/05/2018 11:16 AM, Amit Singh Tomar wrote:
Signed-off-by: Amit Singh Tomar
With one change (see below):
Acked-by: Julien Grall
[...]
+/*
+ * MVEBU UART wait UART to be ready to transmit
+ * xb: register which contains the UART base address
+ * c: scratch register
+ */
+.macro ea
On 06/04/18 11:03, Julien Grall wrote:
> Hi,
>
> On 04/06/2018 09:00 AM, Wei Liu wrote:
>> On Thu, Apr 05, 2018 at 07:54:26PM +0100, Andrew Cooper wrote:
>>> c/s 74fd984ae "tools/libxl: Drop xc_domain_configuration_t from
>>> libxl__domain_build_state" removed state->config completely, but the GIC
(+Juergen)
Hi,
On 04/05/2018 11:16 AM, Amit Singh Tomar wrote:
This patch adds driver for UART controller found on Armada 3700 SoC.
There is no reference manuals available for 3700 SoC in public and it
is derived by looking at Linux driver[1].
[1]https://github.com/torvalds/linux/blob/master/
flight 121960 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121960/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 121876
build-armhf
On 04/06/2018 12:13 PM, Juergen Gross wrote:
On 19/03/18 08:22, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello, all!
In order to provide explicit synchronization between backend and
frontend the following changes are introduced in the protocol:
- bump protocol version to
On 19/03/18 08:22, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Hello, all!
>
> In order to provide explicit synchronization between backend and
> frontend the following changes are introduced in the protocol:
> - bump protocol version to 2
> - add new ring buffer for sen
Hi,
On 04/06/2018 09:00 AM, Wei Liu wrote:
> On Thu, Apr 05, 2018 at 07:54:26PM +0100, Andrew Cooper wrote:
>> c/s 74fd984ae "tools/libxl: Drop xc_domain_configuration_t from
>> libxl__domain_build_state" removed state->config completely, but the GIC
>> version is available in info. Use the up-to
On 04/05/2018 03:10 PM, Julien Grall wrote:
Hi,
On 02/04/18 12:17, Manish Jaggi wrote:
On 04/02/2018 04:33 PM, Manish Jaggi wrote:
On 03/27/2018 03:48 PM, Marc Zyngier wrote:
On 27/03/18 10:07, Manish Jaggi wrote:
This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed31
On 04/06/2018 09:19 AM, Julien Grall wrote:
> Hi,
>
> On 04/03/2018 04:32 PM, Julien Grall wrote:
>>xen/arch/x86/hvm/ioreq.c| 4 ++--
>
> There is a small clash with Paul's GFN typesafe for ioreq.
> Paul, do you want me to resend a patch for that?
FYI, this is what looks li
On Thu, Apr 05, 2018 at 05:16:27PM +0100, Christian Lindig wrote:
> I think this is a good patch as it reduces the amount of copying. I believe
> it is safe as it is. There is one place where I am a little hesitant:
>
> @@ -291,7 +291,9 @@ let access_logging ~con ~tid ?(data="") ~level
> access_ty
1 - 100 of 114 matches
Mail list logo
