flight 132380 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132380/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 132230
test-amd64-amd64-xl-qemuu-win7-amd64
Any comments from Xen community?
Konrad?
On 1/15/19 4:44 PM, Hans Verkuil wrote:
> Hi Oleksandr,
>
> Just two remaining comments:
>
> On 1/15/19 10:38 AM, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> This is the ABI for the two halves of a para-virtualized
>> camera drive
On 22/01/2019 15:35, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Sta
flight 132395 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132395/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 132271
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
Some frontend drivers will handle dynamic resizing of PV disks, so set up
the BlockDevOps resize_cb() method during xen_block_realize() to allow
this to be done.
Signed-off-by: Paul Durrant
---
Cc: Stefan Hajnoczi
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: Kevin Wolf
Cc: Max Reitz
---
hw
The current check for the present bit is wrong, since the present bit
is located in the low part of the entry.
Fixes: e8afe1124cc1 ("iommu: elide flushing for higher order map/unmap
operations")
Signed-off-by: Roger Pau Monné
---
Cc: Suravee Suthikulpanit
Cc: Brian Woods
Cc: Juergen Gross
Cc:
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qe
> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 23 January 2019 09:48
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Suravee Suthikulpanit
> ; Brian Woods ;
> Juergen Gross ; Paul Durrant
> Subject: [PATCH for-4.12] amd/iommu: fix present bi
From: Andrii Anisov
Taking decission by `need_iommu_pt_sync()` make us never kicking
`iommu_iotlb_flush()` for IOMMUs which do share TLB with CPU.
So check `has_iommu_pt()` instead.
Signed-off-by: Andrii Anisov
---
Julien,
Could you please look at this, IMO there is a mistake here.
x86 uses
flight 132424 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132424/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 08b908ba63dee8bc313983c5e412852cbcbcda85
baseline version:
xen 1912
Hi all,
it looks as if March 25/26 in Frankfurt or Cambridge is the best option. For
Matt, this would mean that he can only attend the first day, but I believe this
would be OK. Maybe Robin can attend the second day, instead of Matt. Before we
finalise the dates, I will need to secure the meeti
On 23/01/2019 10:47, Roger Pau Monne wrote:
> The current check for the present bit is wrong, since the present bit
> is located in the low part of the entry.
>
> Fixes: e8afe1124cc1 ("iommu: elide flushing for higher order map/unmap
> operations")
> Signed-off-by: Roger Pau Monné
Release-acked
>>> On 22.01.19 at 19:23, wrote:
> On 22/01/2019 10:46, Jan Beulich wrote:
>>
>>> Regardless of the
>>> alignment though, the fact that order comes from a hypercall argument and
>>> may
>>> not match any of the orders supported by the IOMMU implementation makes me
>>> think that using a page c
>>> On 22.01.19 at 18:02, wrote:
> On Mon, Jan 21, 2019 at 04:27:38AM -0700, Jan Beulich wrote:
>> >>> On 18.01.19 at 17:03, wrote:
>> > ...and remove alignment assertions.
>> >
>> > Testing shows that certain callers of iommu_legacy_map/unmap() specify
>> > order > 0 ranges that are not order a
Variables declared in a switch statement before any case statements
cannot be initialized, so move all instances out of the switches.
After this, future always-initialized stack variables will work
and not throw warnings like this:
fs/fcntl.c: In function ‘send_sigio_to_task’:
fs/fcntl.c:738:13: w
Adds test for stack initialization coverage. We have several build options
that control the level of stack variable initialization. This test lets us
visualize which options cover which cases, and provide tests for options
that are currently not available (padding initialization).
All options pass
This adds a new plugin "stackinit" that attempts to perform unconditional
initialization of all stack variables[1]. It has wider effects than
GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y since BYREF_ALL does not consider
non-structures. A notable weakness is that padding bytes in many cases
remain uninitializ
This attempts to duplicate the proposed gcc option -finit-local-vars[1]
in an effort to implement the "always initialize local variables" kernel
development goal[2].
Enabling CONFIG_GCC_PLUGIN_STACKINIT should stop all "uninitialized
stack variable" flaws as long as they don't depend on being zero
>>> On 21.01.19 at 20:02, wrote:
> Update parse_efi_param() to use parse_boolean() for "rs", so it behaves
> like other Xen booleans.
>
> However, change "attr=uc" to not be a boolean. "no-attr=uc" is ambiguous and
> shouldn't be accepted, but accept "attr=no" as an acceptable alternative.
>
>
>>> On 21.01.19 at 20:02, wrote:
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -38,7 +38,7 @@ bool_t __read_mostly iommu_intremap = 1;
>
> bool __hwdom_initdata iommu_hwdom_strict;
> bool __read_mostly iommu_hwdom_passthrough;
> -int8_t __hwdom_initdata i
>>> On 21.01.19 at 16:52, wrote:
> On Mon, Jan 21, 2019 at 03:37:19PM +, Andrew Cooper wrote:
>> Function pointer calls are far more expensive in a post-Spectre world, and
>> this one doesn't need to be.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
>
> Reviewed-by: Wei Li
On 21/01/2019 16:37, Andrew Cooper wrote:
> These are all minor fixes from some recent PVH work. They are all limited to
> the boot path, and low-risk nice-to-have's for 4.12.
>
> Andrew Cooper (3):
> x86/pvh-dom0: Remove unnecessary function pointer call from
> modify_identity_mmio()
> x86/
(+ Paul)
Hello,
On 23/01/2019 10:12, Andrii Anisov wrote:
From: Andrii Anisov
Taking decission by `need_iommu_pt_sync()` make us never kicking
s/decission/decision/
`iommu_iotlb_flush()` for IOMMUs which do share TLB with CPU.
I am not aware of platform where we share the TLB with the C
>>> On 21.01.19 at 16:37, wrote:
> --- a/xen/arch/x86/guest/pvh-boot.c
> +++ b/xen/arch/x86/guest/pvh-boot.c
> @@ -38,12 +38,20 @@ static const char *__initdata pvh_loader = "PVH
> Directboot";
> static void __init convert_pvh_info(multiboot_info_t **mbi,
> m
>>> On 21.01.19 at 16:37, wrote:
> The current rendering of PVH start info in unnecessarily verbose, and doesn't
> clearly separate decimal and hex numbers.
As expressed on earlier occasions, I think blindly adding 0x in
all cases goes too far. When context makes sufficiently clear
that it's a he
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 23 January 2019 11:34
> To: Andrii Anisov ; xen-
> de...@lists.xenproject.org
> Cc: Stefano Stabellini ; Andrii Anisov
> ; Paul Durrant
> Subject: Re: [RFC] arm/p2m: call iommu iotlb flush if iommu exists and
>
When checking for being an hvm domain, or PV domain, we have to make
sure that speculation cannot bypass that check, and eventually access
data that should not end up in cache for the current domain type.
Signed-off-by: Norbert Manthey
---
xen/include/xen/sched.h | 6 --
1 file changed, 4 i
Guests can issue grant table operations and provide guest controlled
data to them. This data is also used for memory loads. To avoid
speculative out-of-bound accesses, we use the array_index_nospec macro
where applicable. However, there are also memory accesses that cannot
be protected by a single
This commit introduces the configuration option L1TF_LFENCE that allows
to control the implementation of the protection of privilege checks via
lfence instructions. The following four alternatives are provided:
- not injecting lfence instructions
- inject an lfence instruction for both outcomes
Dear all,
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative out-o
Checks of domain properties, such as is_hardware_domain or is_hvm_domain,
might be bypassed by speculatively executing these instructions. A reason
for bypassing these checks is that these macros access the domain
structure via a pointer, and check a certain field. Since this memory
access is slow,
The get_page_from_gfn method returns a pointer to a page that belongs
to a gfn. Before returning the pointer, the gfn is checked for being
valid. Under speculation, these checks can be bypassed, so that
the function get_page is still executed partially. Consequently, the
function page_get_owner_and
There are multiple arrays in the HVM interface that are accessed
with indices that are provided by the guest. To avoid speculative
out-of-bound accesses, we use the array_index_nospec macro.
When blocking speculative out-of-bound accesses, we can classify arrays
into dynamic arrays and static arra
When interacting with io apic, a guest can specify values that are used
as index to structures, and whose values are not compared against
upper bounds to prevent speculative out-of-bound accesses. This change
prevents these speculative accesses.
This commit is part of the SpectreV1+L1TF mitigation
When interacting with hpet, read and write operations can be executed
during instruction emulation, where the guest controls the data that
is used. As it is hard to predict the number of instructions that are
executed speculatively, we prevent out-of-bound accesses by using the
array_index_nospec f
On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
Guests can issue event channel interaction with guest specified data.
To avoid speculative out-of-bound accesses, we use the nospec macros.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
---
xen/common/event_channel.c | 25
During instruction emulation, the cpuid instruction is emulated with
data that is controlled by the guest. As speculation might pass bound
checks, we have to ensure that no out-of-bound loads are possible.
To not rely on the compiler to perform value propagation, instead of
using the array_index_n
While the lfence instruction was added for all x86 platform in the
beginning, it's useful to not block platforms that are not affected
by the L1TF vulnerability. Therefore, the lfence instruction should
only be introduced, in case the current CPU is an Intel CPU that is
capable of hyper threading.
On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > Variables declared in a switch statement before any case statements
> > cannot be initialized, so move all instances out of the switches.
> > After this, future always-initialized stack
On Wed, 23 Jan 2019 at 13:09, Jann Horn wrote:
>
> On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > > Variables declared in a switch statement before any case statements
> > > cannot be initialized, so move all instances out of the
On 23/01/2019 11:42, Jan Beulich wrote:
>
>> --- a/xen/arch/x86/guest/pvh-boot.c
>> +++ b/xen/arch/x86/guest/pvh-boot.c
>> @@ -123,28 +123,29 @@ void __init pvh_print_info(void)
>> const struct hvm_modlist_entry *entry;
>> unsigned int i;
>>
>> -ASSERT(pvh_info->magic == XEN_HVM_STA
On 23.01.19 13:33, Julien Grall wrote:
Do you mean sharing the P2M?
For sure!
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Hello Paul,
On 23.01.19 13:45, Paul Durrant wrote:
Yes, this was a mistake when moving from the old macros and need_iommu. Andrii
is correct that need_iommu_pt_sync() is supposed to gate whether an explicit
map/unmap is needed. The need for flush should only depend on has_iommu_pt().
So I fix
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 23 January 2019 12:40
> To: Paul Durrant ; 'Julien Grall'
> ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Andrii Anisov
>
> Subject: Re: [RFC] arm/p2m: call iommu iotlb flush if iommu exists a
From: Andrii Anisov
Taking decision by `need_iommu_pt_sync()` make us never kicking
`iommu_iotlb_flush()` for IOMMUs which do share P2M with CPU.
So check `has_iommu_pt()` instead.
Signed-off-by: Andrii Anisov
---
Changes in v2:
Fixed a missprint and a nit in a commit message
xen/arch/arm
> -Original Message-
> From: Andrii Anisov [mailto:andrii.ani...@gmail.com]
> Sent: 23 January 2019 12:50
> To: xen-devel@lists.xenproject.org
> Cc: Julien Grall ; Stefano Stabellini
> ; Paul Durrant ; Juergen
> Gross ; Andrii Anisov
> Subject: [PATCH v2 for-4.12] arm/p2m: call iommu iotlb
On 23/01/2019 13:50, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Taking decision by `need_iommu_pt_sync()` make us never kicking
> `iommu_iotlb_flush()` for IOMMUs which do share P2M with CPU.
> So check `has_iommu_pt()` instead.
>
> Signed-off-by: Andrii Anisov
Release-acked-by: Juergen Gr
>>> On 23.01.19 at 12:51, wrote:
> --- a/xen/include/xen/nospec.h
> +++ b/xen/include/xen/nospec.h
> @@ -58,6 +58,21 @@ static inline unsigned long
> array_index_mask_nospec(unsigned long index,
> (typeof(_i)) (_i & _mask); \
> })
>
> +/*
> + * all
>>> On 23.01.19 at 12:51, wrote:
> This commit introduces the configuration option L1TF_LFENCE that allows
> to control the implementation of the protection of privilege checks via
> lfence instructions. The following four alternatives are provided:
>
> - not injecting lfence instructions
> - i
Hi,
On 23/01/2019 13:07, Jan Beulich wrote:
On 23.01.19 at 12:51, wrote:
--- a/xen/include/xen/nospec.h
+++ b/xen/include/xen/nospec.h
@@ -58,6 +58,21 @@ static inline unsigned long array_index_mask_nospec(unsigned
long index,
(typeof(_i)) (_i & _mask);
>>> On 23.01.19 at 12:51, wrote:
> --- a/xen/include/xen/nospec.h
> +++ b/xen/include/xen/nospec.h
> @@ -58,6 +58,21 @@ static inline unsigned long
> array_index_mask_nospec(unsigned long index,
> (typeof(_i)) (_i & _mask); \
> })
>
> +/*
> + * all
> On Jan 23, 2019, at 5:09 AM, Jann Horn wrote:
>
> AFAICS this only applies to switch statements (because they jump to a
> case and don't execute stuff at the start of the block), not blocks
> after if/while/... .
It bothers me that we are going out of our way to deprecate valid C constructs
Hi,
On 23/01/2019 11:51, Norbert Manthey wrote:
diff --git a/xen/include/xen/nospec.h b/xen/include/xen/nospec.h
--- a/xen/include/xen/nospec.h
+++ b/xen/include/xen/nospec.h
@@ -68,10 +68,18 @@ static inline bool lfence_true(void) { return true; }
#endif
/*
- * protect evaluation of con
On 23/01/2019 12:50, Andrii Anisov wrote:
From: Andrii Anisov
Taking decision by `need_iommu_pt_sync()` make us never kicking
`iommu_iotlb_flush()` for IOMMUs which do share P2M with CPU.
So check `has_iommu_pt()` instead.
Please mention the bug was introduced by commit 91d4eca7ad "mm / iom
(+ Juergen)
Hi Juergen,
On 22/01/2019 23:22, Stefano Stabellini wrote:
On Fri, 30 Nov 2018, Julien Grall wrote:
GICv2 and GICv3 supports up to 1020 interrupts. However, the value computed
from GICD_TYPER.ITLinesNumber can be up to 1024. On GICv3, we will end up to
write in reserved registers t
Juergen,
On 23.01.19 15:26, Julien Grall wrote:
Please mention the bug was introduced by commit 91d4eca7ad "mm / iommu: split
need_iommu() into has_iommu_pt() and need_iommu_pt_sync()".
Should I send v3?.
With that:
Acked-by: Julien Grall
--
Sincerely,
Andrii Anisov.
___
On 23/01/2019 13:32, Andrii Anisov wrote:
Juergen,
On 23.01.19 15:26, Julien Grall wrote:
Please mention the bug was introduced by commit 91d4eca7ad "mm / iommu: split
need_iommu() into has_iommu_pt() and need_iommu_pt_sync()".
Should I send v3?.
No need, I will fix it on commit.
Cheers,
On 23.01.19 15:33, Julien Grall wrote:
On 23.01.19 15:26, Julien Grall wrote:
No need, I will fix it on commit.
Thank you.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman
On 23/01/2019 14:29, Julien Grall wrote:
> (+ Juergen)
>
> Hi Juergen,
>
> On 22/01/2019 23:22, Stefano Stabellini wrote:
>> On Fri, 30 Nov 2018, Julien Grall wrote:
>>> GICv2 and GICv3 supports up to 1020 interrupts. However, the value
>>> computed
>>> from GICD_TYPER.ITLinesNumber can be up to
>>> On 23.01.19 at 12:51, wrote:
> @@ -1268,7 +1272,8 @@ unmap_common(
> }
>
> smp_rmb();
> -map = &maptrack_entry(lgt, op->handle);
> +map = &maptrack_entry(lgt, array_index_nospec(op->handle,
> + lgt->maptrack_limit));
It migh
>>> On 23.01.19 at 14:24, wrote:
> On 23/01/2019 11:51, Norbert Manthey wrote:
>> --- a/xen/include/xen/nospec.h
>> +++ b/xen/include/xen/nospec.h
>> @@ -68,10 +68,18 @@ static inline bool lfence_true(void) { return true; }
>> #endif
>>
>> /*
>> - * protect evaluation of conditional with re
>>> On 23.01.19 at 14:20, wrote:
> On 23/01/2019 13:07, Jan Beulich wrote:
> On 23.01.19 at 12:51, wrote:
>>> --- a/xen/include/xen/nospec.h
>>> +++ b/xen/include/xen/nospec.h
>>> @@ -58,6 +58,21 @@ static inline unsigned long
>>> array_index_mask_nospec(unsigned long index,
>>> (typeo
Hi Jan,
On 23/01/2019 13:39, Jan Beulich wrote:
On 23.01.19 at 14:24, wrote:
On 23/01/2019 11:51, Norbert Manthey wrote:
--- a/xen/include/xen/nospec.h
+++ b/xen/include/xen/nospec.h
@@ -68,10 +68,18 @@ static inline bool lfence_true(void) { return true; }
#endif
/*
- * protect eva
On Wed, 23 Jan 2019, Greg KH wrote:
> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>> Variables declared in a switch statement before any case statements
>> cannot be initialized, so move all instances out of the switches.
>> After this, future always-initialized stack variables will
On Wed, 23 Jan 2019, Jani Nikula wrote:
> On Wed, 23 Jan 2019, Greg KH wrote:
>> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>>> Variables declared in a switch statement before any case statements
>>> cannot be initialized, so move all instances out of the switches.
>>> After this,
> On Jan 22, 2019, at 1:06 AM, Juergen Gross wrote:
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index b9a667d36c55..7fc2a87110a3 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -96,10 +96,16 @@ void mem_hotplug_done(void)
> cpus_read_unlock();
> }
>
>
On 23/01/2019 15:35, William Kucharski wrote:
>
>
>> On Jan 22, 2019, at 1:06 AM, Juergen Gross wrote:
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index b9a667d36c55..7fc2a87110a3 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -96,10 +96,16 @@ void mem
>>> On 23.01.19 at 14:44, wrote:
> On 23/01/2019 13:39, Jan Beulich wrote:
> On 23.01.19 at 14:24, wrote:
>>> On 23/01/2019 11:51, Norbert Manthey wrote:
--- a/xen/include/xen/nospec.h
+++ b/xen/include/xen/nospec.h
@@ -68,10 +68,18 @@ static inline bool lfence_true(void) { ret
On Wed, 23 Jan 2019, Jani Nikula wrote:
> On Wed, 23 Jan 2019, Greg KH wrote:
> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> >> Variables declared in a switch statement before any case statements
> >> cannot be initialized, so move all instances out of the switches.
> >> After t
The progression of multi-vcpu support in Xen (originally a single pointer,
then an embedded d->vcpu[] array, then a dynamically allocated array) has
resulted in a large quantity of ad-hoc code for looking a vcpu up by id, and a
large number of ways that the toolstack can cause Xen to trip over a NU
On 23/01/2019 14:59, Andrew Cooper wrote:
> The progression of multi-vcpu support in Xen (originally a single pointer,
> then an embedded d->vcpu[] array, then a dynamically allocated array) has
> resulted in a large quantity of ad-hoc code for looking a vcpu up by id, and a
> large number of ways
On 23/01/2019 15:59, Andrew Cooper wrote:
> The progression of multi-vcpu support in Xen (originally a single pointer,
> then an embedded d->vcpu[] array, then a dynamically allocated array) has
> resulted in a large quantity of ad-hoc code for looking a vcpu up by id, and a
> large number of ways
flight 132403 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132403/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 131842
On Wed, 23 Jan 2019, Edwin Zimmerman wrote:
> On Wed, 23 Jan 2019, Jani Nikula wrote:
>> On Wed, 23 Jan 2019, Greg KH wrote:
>> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
>> >> Variables declared in a switch statement before any case statements
>> >> cannot be initialized, so m
flight 132402 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132402/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 129313
test-amd64-amd64-amd
Hello Wei,
On 13.02.18 14:24, Wei Liu wrote:
On Mon, Feb 12, 2018 at 07:22:27PM +0200, Oleksandr Grytsov wrote:
Is it done by design or there is an issue with parse_json?
If it is done by design then the solution proposed by you (update_config
hook)
will solve this problem. But handling default
flight 132436 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132436/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 23.01.19 at 15:59, wrote:
> +static inline struct vcpu *domain_vcpu(const struct domain *d,
> + unsigned int vcpu_id)
> +{
> +unsigned int idx = array_index_nospec(vcpu_id, d->max_vcpus);
> +
> +return idx >= d->max_vcpus ? NULL : d->vcpu[idx];
Hi Daniel.
On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here
Hi Dario,
Thanks for your comments.
On Fri, Jan 18, 2019 at 8:38 PM Dario Faggioli wrote:
>
> On Sun, 2018-12-23 at 19:51 +0530, Praveen Kumar wrote:
> > diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> > index 623a325ceb..2463a25f87 100644
> > --- a/xen/common/sched_credit2
On 23/01/2019 17:01, Jan Beulich wrote:
On 23.01.19 at 15:59, wrote:
>> +static inline struct vcpu *domain_vcpu(const struct domain *d,
>> + unsigned int vcpu_id)
>> +{
>> +unsigned int idx = array_index_nospec(vcpu_id, d->max_vcpus);
>> +
>> +ret
Hello Julien,
On 22.01.19 16:31, Julien Grall wrote:
IMO, the pure fixes, like patch 2, and the first hunk of patch 1 should be OK
for 4.12.
The first hunk of patch 1 aside, we never supported the new IOMMU bindings nor
unsharing the P2M. So what do you actually fix?
Supporting unshared P2M
The order of the page_order and the flags parameters are inverted in
the call to iommu_map made in iommu_hwdom_init.
Fixes: e8afe1124cc1 ("iommu: elide flushing for higher order map/unmap
operations")
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Paul Durrant
---
xen/drivers/passthro
On 23/01/2019 17:53, Andrii Anisov wrote:
Hello Julien,
Hi,
On 22.01.19 16:31, Julien Grall wrote:
IMO, the pure fixes, like patch 2, and the first hunk of patch 1 should be OK
for 4.12.
The first hunk of patch 1 aside, we never supported the new IOMMU bindings nor
unsharing the P2M. So
On Wed, Jan 23, 2019 at 12:39:21AM +0100, Sander Eikelenboom wrote:
> On 22/01/2019 17:14, Roger Pau Monné wrote:
> > On Sun, Jan 20, 2019 at 11:09:25PM +0100, Sander Eikelenboom wrote:
> >> On 18/01/2019 18:56, Roger Pau Monné wrote:
> >>> On Fri, Jan 18, 2019 at 03:17:57PM +0100, Sander Eikelenbo
On 23.01.19 20:14, Julien Grall wrote:
I can queue the first hunk for Xen 4.13.
For 4.13? Well I hope we will manage to upstream the whole series until then.
This statement is only correct if the IOMMU has been actively blacklisted by
Xen. In the case of the SMMU driver, this is done by arm_
On 23/01/2019 18:29, Andrii Anisov wrote:
On 23.01.19 20:14, Julien Grall wrote:
I can queue the first hunk for Xen 4.13.
For 4.13? Well I hope we will manage to upstream the whole series until then.
If you plan to resend it separately, I can apply to the next branch regardless
the rest o
On Thu, Jan 24, 2019 at 4:44 AM Jani Nikula wrote:
>
> On Wed, 23 Jan 2019, Edwin Zimmerman wrote:
> > On Wed, 23 Jan 2019, Jani Nikula wrote:
> >> On Wed, 23 Jan 2019, Greg KH wrote:
> >> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> >> >> Variables declared in a switch statem
On Wed, 2019-01-23 at 03:03 -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
>
> fs
On Wed, Jan 23, 2019 at 04:17:30PM +0200, Jani Nikula wrote:
> Can't have:
>
> switch (i) {
> int j;
> case 0:
> /* ... */
> }
>
> because it can't be turned into:
>
> switch (i) {
> int j = 0; /* not valid C */
> case 0:
>
flight 132411 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132411/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 132318
test-armhf-armhf-libvirt-raw 13 saveresto
On 23/01/2019 19:25, Roger Pau Monné wrote:
> On Wed, Jan 23, 2019 at 12:39:21AM +0100, Sander Eikelenboom wrote:
>> On 22/01/2019 17:14, Roger Pau Monné wrote:
>>> On Sun, Jan 20, 2019 at 11:09:25PM +0100, Sander Eikelenboom wrote:
On 18/01/2019 18:56, Roger Pau Monné wrote:
> On Fri, Jan
On Thu, Jan 24, 2019 at 8:18 AM Matthew Wilcox wrote:
>
> On Wed, Jan 23, 2019 at 04:17:30PM +0200, Jani Nikula wrote:
> > Can't have:
> >
> > switch (i) {
> > int j;
> > case 0:
> > /* ... */
> > }
> >
> > because it can't be turned into:
> >
> >
On Tue, 22 Jan 2019, h...@infradead.org wrote:
> On Tue, Jan 22, 2019 at 11:59:31AM -0800, Stefano Stabellini wrote:
> > > if (!virtio_has_iommu_quirk(vdev))
> > > return true;
> > >
> > > @@ -260,7 +262,7 @@ static bool vring_use_dma_api(struct virtio_device
> > > *vdev)
> > >*
On Wed, Jan 23, 2019 at 01:04:33PM -0800, Stefano Stabellini wrote:
> If vring_use_dma_api is actually supposed to return true when
> dma_dev->dma_mem is set, then both Peng's patch and the patch I wrote
> are not fixing the real issue here.
>
> I don't know enough about remoteproc to know where t
On Mon, Jan 21, 2019 at 4:03 AM Jan Beulich wrote:
>
> >>> On 20.01.19 at 22:18, wrote:
> > On Thu, Jan 17, 2019 at 3:25 AM Jan Beulich wrote:
> >>
> >> >>> On 17.01.19 at 08:22, wrote:
> >
> > 3. A challenge with using the "struct" form, following from the result
> > of point 2, occurs when it
flight 132441 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132441/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
examine-laxton1 broken
examine-rochester0
flight 132450 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132450/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Wed, 28 Nov 2018, Julien Grall wrote:
> A follow-up patch will need to generate the VTTBR in a few places.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/p2m.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index
1 - 100 of 131 matches
Mail list logo
