/commits/Paul-Durrant/xen-privcmd-add-IOCTL_PRIVCMD_MMAP_RESOURCE/20180406-121749
base: https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https
flight 121859 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121859/
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
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 the xpti boot parameter handling to xen/arch/x86/pv
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 remove all TLB
entries.
In order to avoid states
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 option "invpcid" for controlling the use of
INVPCID (d
This patch series aims at reducing the overhead of the XPTI Meltdown
mitigation.
Patch 1 had been posted before, the main changes in this patch are due
to addressing Jan's comments on my first version. The main objective of
that patch is to avoid copying the L4 page table each time the guest is
be
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 kernel mode
- guest active and in user mode
- hypervis
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 entries in that case.
Signed-off-by: Juergen Gross
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, e.g. when handling
interrupts or any hypercall no
Today cpu_info->xen_cr3 is either 0 to indicate %cr3 doesn't need to
be switched on entry to Xen, or negative for keeping the value while
indicating not to restore %cr3, or positive in case %cr3 is to be
restored.
Switch to use a flag byte instead of a negative xen_cr3 value in order
to allow %cr3
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-date version.
>
> Signed-off-by: Andrew Cooper
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:
> On Thu, Apr 5, 2018 at 2:06 PM, Juergen Gross wrote:
On 06/04/18 10:00, 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-date vers
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?
Cheers,
--
Julien Grall
___
Xen-devel
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
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 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
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 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
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
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
(+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/
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
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
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/
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
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|
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
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
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:
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 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 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
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 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
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 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 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 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 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
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 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
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-
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
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 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
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
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,
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:
> 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 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 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
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
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
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 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 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 '}
>
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 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 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 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 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 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 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 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 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 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 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.
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 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
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 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
> > >
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 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
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 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
"#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
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
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
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
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 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
> 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
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,
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
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
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
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
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
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
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
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 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 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
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 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
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
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
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
1 - 100 of 114 matches
Mail list logo
