On Wed, Jan 23, 2019 at 08:56:48PM +0100, Sander Eikelenboom wrote:
> 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
Hi Julien
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 2019年1月22日 18:55
> To: Peng Fan ; sstabell...@kernel.org
> Cc: xen-devel@lists.xenproject.org; Andre Przywara
>
> Subject: Re: [PATCH] arm: gic-v3: clear GICR active interrupts
>
> Hi Peng,
>
>
Hi stefano,
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 2019年1月24日 7:44
> To: h...@infradead.org
> Cc: Stefano Stabellini ; Peng Fan
> ; m...@redhat.com; jasow...@redhat.com;
> xen-devel@lists.xenproject.org; linux-remotep...@vger.kernel.org;
>
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 2019年1月23日 4:00
> To: Peng Fan
> Cc: m...@redhat.com; jasow...@redhat.com; sstabell...@kernel.org;
> h...@infradead.org; xen-devel@lists.xenproject.org;
> linux-remotep...@vger.kernel.org;
flight 132408 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132408/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
flight 132426 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132426/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 17dd66970ae1c5980f338a078db9a6046c5adff9
baseline version:
freebsd
flight 132420 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132420/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 131987
Tests which did not
Will inhibit initialization of the domain's argo data structure to
prevent receiving any messages or notifications and access to any of
the argo hypercall operations.
Signed-off-by: Christopher Clark
Acked-by: Daniel De Graaf
v3 Daniel/Jan: add to the default xsm policy for enable
v3 Add
Takes a single argument: a handle to the ring unregistration struct,
which specifies the port and partner domain id or wildcard.
The ring's entry is removed from the hashtable of registered rings;
any entries for pending notifications are removed; and the ring is
unmapped from Xen's address
The register op is used by a domain to register a region of memory for
receiving messages from either a specified other domain, or, if specifying a
wildcard, any domain.
This operation creates a mapping within Xen's private address space that
will remain resident for the lifetime of the ring. In
Signed-off-by: Christopher Clark
v5 whitespace: tabs
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e99d39e..a0cda4f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -158,6 +158,13 @@ S: Supported
F: xen/arch/x86/hvm/svm/
F:
sendv operation is invoked to perform a synchronous send of buffers
contained in iovs to a remote domain's registered ring.
It takes:
* A destination address (domid, port) for the ring to send to.
It performs a most-specific match lookup, to allow for wildcard.
* A source address, used to
Queries for data about space availability in registered rings and
causes notification to be sent when space has become available.
The hypercall op populates a supplied data structure with information about
ring state and if insufficient space is currently available in a given ring,
the hypervisor
EMSGSIZE: Argo's sendv operation will return EMSGSIZE when an excess amount
of data, across all iovs, has been supplied, exceeding either the statically
configured maximum size of a transmittable message, or the (variable) size
of the ring registered by the destination domain.
ECONNREFUSED:
Default policy: allow.
Signed-off-by: Christopher Clark
Reviewed-by: Paul Durrant
Acked-by: Daniel De Graaf
v3 Daniel/Jan: add to the default xsm policy for the send op
v3 Add Daniel's Acked-by
v2: reordered commit sequence to after sendv implementation
v1 feedback Jan #16: apply const to
Signed-off-by: Christopher Clark
Acked-by: Daniel De Graaf
v3 #10 Roger: drop out label, use return -EFAULT in fill_ring_data
v3: Add Daniel's Acked-by
---
xen/common/argo.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/xen/common/argo.c b/xen/common/argo.c
index
XSM controls for argo ring registration with two distinct cases, where
the ring being registered is:
1) Single source: registering a ring for communication to receive messages
from a specified single other domain.
Default policy: allow.
2) Any source: registering a
Defines CONFIG_ARGO when enabled. Default: disabled.
When the Kconfig option is enabled, the Argo hypercall implementation
will be included, allowing use of the hypervisor-mediated interdomain
communication mechanism.
Argo is implemented for x86 and ARM hardware platforms.
Availability of the
A convenience for working on development of the argo subsystem:
setting a #define variable enables additional debug messages.
Signed-off-by: Christopher Clark
Acked-by: Jan Beulich
Reviewed-by: Roger Pau Monné
===
Jan's further remark given with the Ack:
"This would better be an inline
Initialises basic data structures and performs teardown of argo state
for domain shutdown.
Inclusion of the Argo implementation is dependent on CONFIG_ARGO.
Introduces a new Xen command line parameter 'argo': bool to enable/disable
the argo hypercall. Defaults to disabled.
New headers:
Presence is gated upon CONFIG_ARGO.
Registers the hypercall previously reserved for this.
Takes 5 arguments, does nothing and returns -ENOSYS.
Will be avoiding a compat ABI by using fixed-size types in hypercall ops so
HYPERCALL, rather than COMPAT_CALL, is the correct macro for the hypercall
ARM port of c/s bb544585: "introduce guest_handle_for_field()"
This helper turns a field of a GUEST_HANDLE into a GUEST_HANDLE.
Signed-off-by: Christopher Clark
Reviewed-by: Paul Durrant
Reviewed-by: Stefano Stabellini
===
v3: Added Stefano's Reviewed-by
v2: Added Paul's Reviewed-by
---
Posting an updated version (six) of this series with fixes for people
who are testing. Does not include changes for open discussion items.
Fixes include:
* Compat validation macros:
- struct fields converted to use "struct form" in their declarations
- dropped the overrides; using the struct
flight 132419 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132419/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
129475
flight 132413 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132413/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125898
test-armhf-armhf-libvirt 14
On Wed, 28 Nov 2018, Julien Grall wrote:
> Early version of Cortex-A76 can end-up with corrupt TLBs if they
> speculate an AT instruction while the S1/S2 system registers are in an
> inconsistent state.
>
> This can happen during guest context switch and when invalidating the
> TLBs for other
On Wed, 28 Nov 2018, Julien Grall wrote:
> Until recently, kernel/initrd/dtb were loaded using guest VA and
> therefore requiring to restore temporarily the P2M. This reworked in a
^ was
> series of commits (up to 9292086 "xen/arm:
On Wed, 28 Nov 2018, Julien Grall wrote:
> Only {A,F,I}MO are necessary to receive interrupts until a guest vCPU is
> loaded.
>
> The rest have no effect on Xen and it is better to avoid setting them.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/traps.c | 8 ++--
> 1 file changed,
On Wed, 23 Jan 2019, h...@infradead.org wrote:
> 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.
>
On Wed, 28 Nov 2018, Julien Grall wrote:
> The EL1 translation regime is out-of-context when running at EL2. This
> means the processor cannot speculate memory accesses using the registers
> associated to that regime.
>
> An isb() is only need if Xen is going to use the translation regime
On Wed, 28 Nov 2018, Julien Grall wrote:
> A follow-up patch will require to allocate the root page-table without
> having a domain in hand.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/p2m.c | 16
> 1 file changed, 12 insertions(+), 4
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
>
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
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
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
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
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 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 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,
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
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:
>
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:
>
>
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
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
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
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
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.
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
---
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
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);
>> +
>> +
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
> > ---
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
>>> 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];
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
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
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
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
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.
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
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
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
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
>>> 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) {
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
> 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 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
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
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
>>> 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,
>>>
>>> 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
>>> On 23.01.19 at 12:51, wrote:
> @@ -1268,7 +1272,8 @@ unmap_common(
> }
>
> smp_rmb();
> -map = _entry(lgt, op->handle);
> +map = _entry(lgt, array_index_nospec(op->handle,
> + lgt->maptrack_limit));
It might be better to
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 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
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,
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.
(+ 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
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 /
> 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
>>> 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); \
> })
>
> +/*
> + *
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:
> 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
> -
>>> 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/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
> -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
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
> -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
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
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 ==
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 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
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.
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
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
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
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
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
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
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
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
1 - 100 of 128 matches
Mail list logo
