flight 159134 xen-unstable real [real]
flight 159154 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159134/
http://logs.test-lab.xenproject.org/osstest/logs/159154/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
v4 here: https://lore.kernel.org/patchwork/cover/1378113/
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 25 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 5 +
3
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 24
Add the functions, dev_swiotlb_{alloc,free} to support the memory
allocation from restricted DMA pool.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 2 ++
kernel/dma/direct.c | 30 ++
kernel/dma/swiotlb.c| 34 ++
3
Add is_dev_swiotlb_force() which returns true if the device has
restricted DMA pool (e.g. dev->dev_swiotlb is set).
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 9 +
kernel/dma/swiotlb.c| 5 +
2 files changed, 14 insertions(+)
diff --git a/include/linux/swiotlb.h b/
Add a new wrapper __dma_direct_free_pages() that will be useful later
for dev_swiotlb_free().
Signed-off-by: Claire Chang
---
kernel/dma/direct.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 30ccbc08e229..a76a1a
Refactor swiotlb_tbl_{map,unmap}_single to make the code reusable for
dev_swiotlb_{alloc,free}.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 116 ++-
1 file changed, 71 insertions(+), 45 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dm
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
Introduce the get_swiotlb() getter and update all callers of
is_swiotlb_active(), is_swiotlb_buffer() and get_swiotlb_start() to gain
a struct device argument.
Signed-off-by: Claire Chang
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 4 ++--
include/linux/swiotlb.
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/device.h | 4 ++
kernel/dma/swiotlb.c | 94 +-
2 files changed, 97 insertions(+), 1 deletion(-)
diff --git
Add a new kconfig symbol, DMA_RESTRICTED_POOL, for restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/Kconfig | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 479fc145acfc..97ff9f8dd3c8 100644
--- a/kernel/dma/Kconfig
Refactor swiotlb_late_init_with_tbl to make the code reusable for
restricted DMA pool initialization.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 65
1 file changed, 42 insertions(+), 23 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/ker
Added a new struct, swiotlb, as the IO TLB memory pool descriptor and
moved relevant global variables into that struct.
This will be useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
kernel/dma/swiotlb.c | 327 +++
1 file chang
Move is_swiotlb_buffer() to swiotlb.c and make io_tlb_{start,end}
static, so we can entirely hide struct swiotlb inside of swiotlb.c in
the following patches.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 7 +--
kernel/dma/swiotlb.c| 7 ++-
2 files changed, 7 insertions(+
Add a new function, get_swiotlb_start(), and remove external access to
io_tlb_start, so we can entirely hide struct swiotlb inside of swiotlb.c
in the following patches.
Signed-off-by: Claire Chang
---
arch/powerpc/platforms/pseries/svm.c | 4 ++--
drivers/xen/swiotlb-xen.c| 4 ++--
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for Wi
On Mon, 8 Feb 2021, Julien Grall wrote:
> On Mon, 8 Feb 2021 at 20:24, Stefano Stabellini
> wrote:
> > > @Ian, I think this wants to go in 4.15. Without it, Xen may receive an
> > > IOMMU
> > > fault for DMA transaction using granted page.
> > >
> > > > Backport: 4.12+
> > > >
> > > > ---
> > >
flight 159133 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 broken in 159042
test-amd64-i386-xl-qemuu-w
PCI buses differ from default buses in a few important ways, so it is
important to detect them properly. Normally, PCI buses are expected to
have the following property:
device_type = "pci"
In reality, it is not always the case. To handle PCI bus nodes that
don't have the device_type property
On 2/6/21 5:49 AM, Juergen Gross wrote:
> Add sysfs nodes for each xenbus device showing event statistics (number
> of events and spurious events, number of associated event channels)
> and for setting a spurious event threshold in case a frontend is
> sending too many events without being rogue
On 2/6/21 5:49 AM, Juergen Gross wrote:
> In order to support the possibility of per-device event channel
> settings (e.g. lateeoi spurious event thresholds) add a xenbus device
> pointer to struct irq_info() and modify the related event channel
> binding interfaces to take the pointer to the xen
flight 159146 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159146/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Mon, 8 Feb 2021 at 20:24, Stefano Stabellini wrote:
> > @Ian, I think this wants to go in 4.15. Without it, Xen may receive an IOMMU
> > fault for DMA transaction using granted page.
> >
> > > Backport: 4.12+
> > >
> > > ---
> > >
> > > Given the severity of the bug, I would like to request thi
On Mon, 8 Feb 2021, Julien Grall wrote:
> (+ Jan and Ian for RM/stable decision)
>
> Hi Jan,
>
> On 08/02/2021 18:49, Stefano Stabellini wrote:
> > Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
> > The offending chunk is:
> >
> > #define gnttab_need_iommu_mapping(d)
(+ Jan and Ian for RM/stable decision)
Hi Jan,
On 08/02/2021 18:49, Stefano Stabellini wrote:
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
The offending chunk is:
#define gnttab_need_iommu_mapping(d)\
-(is_domain_direct_mapped(d) && need_iommu(d))
+(
To prevent leaking HVM params via L1TF and similar issues on a
hyperthread pair, let's load values of domains after performing all
relevant checks, and blocking speculative execution.
Furthermore, speculative barriers are re-arranged to make sure we do not
allow guests running on co-located VCPUs
On 2/8/21 3:21 PM, Jan Beulich wrote:
> On 05.02.2021 21:39, Norbert Manthey wrote:
>> To prevent leaking HVM params via L1TF and similar issues on a
>> hyperthread pair, let's load values of domains as late as possible.
>>
>> Furthermore, speculative barriers are re-arranged to make sure we do not
Am Mon, 8 Feb 2021 16:22:54 +
schrieb Ian Jackson :
> With my maintainer hat on: this is a useful development but I am not
> sure about the choice of -T, and the choice to make this a
> migrate-specific option. Most unix things that have an option to
> print timestamps use `-t`. But we have
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
The offending chunk is:
#define gnttab_need_iommu_mapping(d)\
-(is_domain_direct_mapped(d) && need_iommu(d))
+(is_domain_direct_mapped(d) && need_iommu_pt_sync(d))
On ARM we need gnttab_need_iommu_mapping to b
On 08/02/2021 18:19, Rahul Singh wrote:
Hello Julien,
Hi Rahul,
On 8 Feb 2021, at 6:11 pm, Julien Grall wrote:
On 08/02/2021 18:06, Rahul Singh wrote:
On 6 Feb 2021, at 12:38 am, Stefano Stabellini wrote:
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
The offending chu
Hello Julien,
> On 8 Feb 2021, at 6:11 pm, Julien Grall wrote:
>
>
>
> On 08/02/2021 18:06, Rahul Singh wrote:
>>> On 6 Feb 2021, at 12:38 am, Stefano Stabellini
>>> wrote:
>>>
>>> Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
>>> The offending chunk is:
>>>
>>> #define gnttab
On 08/02/2021 18:06, Rahul Singh wrote:
On 6 Feb 2021, at 12:38 am, Stefano Stabellini wrote:
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
The offending chunk is:
#define gnttab_need_iommu_mapping(d)\
-(is_domain_direct_mapped(d) && need_iommu(d))
+
flight 159140 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159140/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hello Stefano,
> On 6 Feb 2021, at 12:38 am, Stefano Stabellini wrote:
>
> Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
> The offending chunk is:
>
> #define gnttab_need_iommu_mapping(d)\
> -(is_domain_direct_mapped(d) && need_iommu(d))
> +(is_domain_di
Olaf Hering writes ("Re: [PATCH v20210111 05/39] tools: add with-xen-scriptdir
configure option"):
> Am Mon, 8 Feb 2021 17:48:31 +
> schrieb Ian Jackson :
> > > It seems the assignments for CONFIG_DIR and XEN_CONFIG_DIR can be moved
> > > up, because $sysconfdir is expected to be set already.
Am Mon, 8 Feb 2021 17:48:31 +
schrieb Ian Jackson :
> > It seems the assignments for CONFIG_DIR and XEN_CONFIG_DIR can be moved up,
> > because $sysconfdir is expected to be set already. As a result the new
> > AC_ARG_WITH= can continue to use "$XEN_CONFIG_DIR/scripts" for the default
> > c
On Sat, 6 Feb 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 06/02/2021 00:38, Stefano Stabellini wrote:
> > Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
>
> Doh :/.
>
> > The offending chunk is: >
> > #define gnttab_need_iommu_mapping(d)\
> > -(is_domain_
Olaf Hering writes ("Re: [PATCH v20210111 05/39] tools: add with-xen-scriptdir
configure option"):
> The reason is the ordering of assignments in the file:
> AC_ARG_WITH comes early in the file, XEN_CONFIG_DIR= is assigned much later.
Ah.
> It seems the assignments for CONFIG_DIR and XEN_CONFIG_
Olaf Hering writes ("Re: [PATCH v20210111 07/39] xl: optionally print
timestamps during xl migrate"):
> Am Mon, 8 Feb 2021 16:22:54 +
> schrieb Ian Jackson :
>
> > I wonder if I can get a quick second option from someone on the API
> > question. Using up a single letter option is something I
Olaf Hering writes ("[PATCH v20210111 15/39] tools/guest: save: move
batch_pfns"):
> The batch_pfns array is already allocated in advance.
> Move it into the preallocated area.
I think these patche really need a review from someone who understands
the migration code. Ideally, Andy, who unfortuna
Am Mon, 8 Feb 2021 16:22:54 +
schrieb Ian Jackson :
> I wonder if I can get a quick second option from someone on the API
> question. Using up a single letter option is something I don't want
> to just rush into.
Maybe put "-T" or "-t" into xl.c:main() instead, so that every command prints
Am Mon, 8 Feb 2021 16:03:29 +
schrieb Ian Jackson :
> I suggest this commit message as a compromise:
>
> Some distros plan for fresh installations will have an empty /etc,
> whose content will not be controlled by the package manager
> anymore.
>
> To make this possible, add a knob t
On Mon, Feb 08, 2021 at 12:50:09PM +0100, Jan Beulich wrote:
> On 08.02.2021 12:05, Roger Pau Monné wrote:
> > On Mon, Feb 08, 2021 at 11:56:01AM +0100, Jan Beulich wrote:
> >> On 05.02.2021 17:15, Roger Pau Monné wrote:
> >>> I've been thinking this all seems doomed when Xen runs in a virtualized
On 08/02/2021 16:25, Ian Jackson wrote:
> Olaf Hering writes ("[PATCH v20210111 08/39] xl: fix description of migrate
> --debug"):
>> xl migrate --debug used to track every pfn in every batch of pages.
>> But these times are gone. Adjust the help text to tell what --debug
>> is supposed to do toda
On Mon, Feb 08, 2021 at 02:59:55PM +0100, Jan Beulich wrote:
> On 08.02.2021 14:19, Roger Pau Monné wrote:
> > On Mon, Feb 08, 2021 at 12:22:25PM +0100, Jan Beulich wrote:
> >> On 08.02.2021 10:38, Roger Pau Monné wrote:
> >>> On Mon, Feb 01, 2021 at 01:43:28PM +0100, Jan Beulich wrote:
> ---
Olaf Hering writes ("[PATCH v20210111 32/39] tools: remove tabs from code
produced by libxl_save_msgs_gen.pl"):
> Signed-off-by: Olaf Hering
Personally I think this is busywork but I am happy to take the patch.
Release-Acked-by: Ian Jackson
Acked-by: Ian Jackson
Release risk is clearly negli
Olaf Hering writes ("[PATCH v20210111 08/39] xl: fix description of migrate
--debug"):
> xl migrate --debug used to track every pfn in every batch of pages.
> But these times are gone. Adjust the help text to tell what --debug
> is supposed to do today.
...
> -Display huge (!) amount of debug info
Ian Jackson writes ("Re: [PATCH v20210111 06/39] Use XEN_SCRIPT_DIR to refer to
/etc/xen/scripts"):
> Olaf Hering writes ("[PATCH v20210111 06/39] Use XEN_SCRIPT_DIR to refer to
> /etc/xen/scripts"):
> > Replace all hardcoded paths to use XEN_SCRIPT_DIR to expand the actual
> > location.
> >
>
Olaf Hering writes ("[PATCH v20210111 07/39] xl: optionally print timestamps
during xl migrate"):
> During 'xl -v.. migrate domU host' a large amount of debug is generated.
> It is difficult to map each line to the sending and receiving side.
> Also the time spent for migration is not reported.
>
Olaf Hering writes ("[PATCH v20210111 06/39] Use XEN_SCRIPT_DIR to refer to
/etc/xen/scripts"):
> Replace all hardcoded paths to use XEN_SCRIPT_DIR to expand the actual
> location.
>
> Update .gitignore.
Reviewed-by: Ian Jackson
Release-Acked-by: Ian Jackson
Although I would have preferred t
Olaf Hering writes ("[PATCH v20210111 05/39] tools: add with-xen-scriptdir
configure option"):
> In the near future all fresh installations will have an empty /etc.
> The content of this directory will not be controlled by the package
> manager anymore. One of the reasons for this move is to make
Olaf Hering writes ("[PATCH v20210111 02/39] xl: use proper name for
bash_completion file"):
> Files in the bash-completion dirs should be named like the commands,
> without suffix. Without this change 'xl' will not be recognized as a
> command with completion support if BASH_COMPLETION_DIR is set
Olaf Hering writes ("[PATCH v20210111 04/39] docs: substitute XEN_CONFIG_DIR in
xl.conf.5"):
> xl(1) opens xl.conf in XEN_CONFIG_DIR.
> Substitute this variable also in the man page.
>
> Signed-off-by: Olaf Hering
> Reviewed-by: Anthony PERARD
Release-Acked-by: Ian Jackson
This is docs. Wor
Olaf Hering writes ("[PATCH v20210111 03/39] docs: remove stale create example
from xl.1"):
> Maybe xm create had a feature to create a domU based on a configuration
> file. xl create requires the '-f' option to refer to a file.
> There is no code to look into XEN_CONFIG_DIR, so remove the example
Olaf Hering writes ("[PATCH v20210111 03/39] docs: remove stale create example
from xl.1"):
> Maybe xm create had a feature to create a domU based on a configuration
> file. xl create requires the '-f' option to refer to a file.
> There is no code to look into XEN_CONFIG_DIR, so remove the example
Olaf Hering writes ("Re: [PATCH v2] tools: create libxensaverestore"):
> Am Mon, 11 Jan 2021 17:46:46 +0100
> schrieb Olaf Hering :
>
> > Move all save/restore related code from libxenguest.so into a separate
> > library libxensaverestore.so.
>
> Was this considered, in general, or for 4.15?
I'
Am Mon, 8 Feb 2021 15:13:55 +
schrieb Ian Jackson :
> I assume this is not targeted for 4.15.
It is, was sent before the deadline I think.
Olaf
pgp_gjah6wNNL.pgp
Description: Digitale Signatur von OpenPGP
Olaf Hering writes ("[PATCH v2] tools: create libxensaverestore"):
> Move all save/restore related code from libxenguest.so into a separate
> library libxensaverestore.so. The only consumer is libxl-save-helper.
> There is no need to have the moved code mapped all the time in binaries
> where libxe
Am Mon, 11 Jan 2021 17:46:46 +0100
schrieb Olaf Hering :
> Move all save/restore related code from libxenguest.so into a separate
> library libxensaverestore.so.
Was this considered, in general, or for 4.15?
Olaf
pgpMHVs0dDqqC.pgp
Description: Digitale Signatur von OpenPGP
On 08.02.21 15:20, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 13:58, Jürgen Groß wrote:
On 08.02.21 14:09, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien G
On 08/02/2021 14:20, Julien Grall wrote:
I believe this will be the case before our "lateeoi" handling is
becoming active (more precise: when our IRQ handler is returning to
handle_fasteoi_irq()), resulting in the possibility of the same race we
are experiencing now.
I am a bit confused what
flight 159138 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159138/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 159054
build-armhf
On 05.02.2021 21:39, Norbert Manthey wrote:
> To prevent leaking HVM params via L1TF and similar issues on a
> hyperthread pair, let's load values of domains as late as possible.
>
> Furthermore, speculative barriers are re-arranged to make sure we do not
> allow guests running on co-located VCPUs
Hi Juergen,
On 08/02/2021 13:58, Jürgen Groß wrote:
On 08.02.21 14:09, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021
On 08.02.2021 14:19, Roger Pau Monné wrote:
> On Mon, Feb 08, 2021 at 12:22:25PM +0100, Jan Beulich wrote:
>> On 08.02.2021 10:38, Roger Pau Monné wrote:
>>> On Mon, Feb 01, 2021 at 01:43:28PM +0100, Jan Beulich wrote:
---
Since CPU0 reads its TSC last on the first iteration, if TSCs were
On 08.02.21 14:09, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien G
flight 159136 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159136/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ovmf-amd64 3 hosts-allocate starved n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host
On Mon, Feb 08, 2021 at 12:22:25PM +0100, Jan Beulich wrote:
> On 08.02.2021 10:38, Roger Pau Monné wrote:
> > On Mon, Feb 01, 2021 at 01:43:28PM +0100, Jan Beulich wrote:
> >> ---
> >> Since CPU0 reads its TSC last on the first iteration, if TSCs were
> >> perfectly sync-ed there shouldn't ever be
Hi Juergen,
On 08/02/2021 12:31, Jürgen Groß wrote:
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how t
On 08.02.21 13:16, Julien Grall wrote:
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is
to re-use what
On 08.02.21 13:23, Jan Beulich wrote:
On 08.02.2021 13:15, Jürgen Groß wrote:
On 08.02.21 12:54, Jan Beulich wrote:
On 08.02.2021 11:59, Jürgen Groß wrote:
On 08.02.21 11:51, Jan Beulich wrote:
On 08.02.2021 11:41, Jürgen Groß wrote:
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49
On 08.02.2021 13:15, Jürgen Groß wrote:
> On 08.02.21 12:54, Jan Beulich wrote:
>> On 08.02.2021 11:59, Jürgen Groß wrote:
>>> On 08.02.21 11:51, Jan Beulich wrote:
On 08.02.2021 11:41, Jürgen Groß wrote:
> On 08.02.21 10:48, Jan Beulich wrote:
>> On 06.02.2021 11:49, Juergen Gross wro
On 08/02/2021 12:14, Jürgen Groß wrote:
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is
to re-use what's already existing rather than trying
On 08.02.21 12:54, Jan Beulich wrote:
On 08.02.2021 11:59, Jürgen Groß wrote:
On 08.02.21 11:51, Jan Beulich wrote:
On 08.02.2021 11:41, Jürgen Groß wrote:
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the produce
On 08.02.21 11:40, Julien Grall wrote:
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is to
re-use what's already existing rather than trying to re-invent the
wheel with an extra lock (
Hi Juergen,
On 08/02/2021 11:48, Jürgen Groß wrote:
On 08.02.21 12:40, Julien Grall wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
---
On 08.02.2021 11:59, Jürgen Groß wrote:
> On 08.02.21 11:51, Jan Beulich wrote:
>> On 08.02.2021 11:41, Jürgen Groß wrote:
>>> On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
> In evtchn_read() use READ_ONCE() for reading the producer index in
> order to
On 08/02/2021 10:59, Jürgen Groß wrote:
On 08.02.21 11:51, Jan Beulich wrote:
Yes, but I don't see an urgent need to fix that, as there would
be thousands of accesses in the kernel needing a fix. A compiler
tearing a naturally aligned access into multiple memory accesses
would be rejected as b
On 08.02.2021 12:05, Roger Pau Monné wrote:
> On Mon, Feb 08, 2021 at 11:56:01AM +0100, Jan Beulich wrote:
>> On 05.02.2021 17:15, Roger Pau Monné wrote:
>>> I've been thinking this all seems doomed when Xen runs in a virtualized
>>> environment, and should likely be disabled. There's no point on t
On 08.02.21 12:40, Julien Grall wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
---
drivers/xen/evtchn.c | 2 +-
1 file changed, 1 ins
On 06/02/2021 10:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
---
drivers/xen/evtchn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
On 08.02.2021 10:38, Roger Pau Monné wrote:
> On Mon, Feb 01, 2021 at 01:43:28PM +0100, Jan Beulich wrote:
>> ---
>> Since CPU0 reads its TSC last on the first iteration, if TSCs were
>> perfectly sync-ed there shouldn't ever be a need to update. However,
>> even on the TSC-reliable system I first
On Mon, Feb 08, 2021 at 11:56:01AM +0100, Jan Beulich wrote:
> On 05.02.2021 17:15, Roger Pau Monné wrote:
> > On Mon, Feb 01, 2021 at 01:43:04PM +0100, Jan Beulich wrote:
> >> The (stime,tsc) tuple is the basis for extrapolation by get_s_time().
> >> Therefore the two better get taken as close to
On 08.02.21 11:51, Jan Beulich wrote:
On 08.02.2021 11:41, Jürgen Groß wrote:
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off
On 05.02.2021 17:15, Roger Pau Monné wrote:
> On Mon, Feb 01, 2021 at 01:43:04PM +0100, Jan Beulich wrote:
>> The (stime,tsc) tuple is the basis for extrapolation by get_s_time().
>> Therefore the two better get taken as close to one another as possible.
>> This means two things: First, reading pla
On 08.02.2021 11:41, Jürgen Groß wrote:
> On 08.02.21 10:48, Jan Beulich wrote:
>> On 06.02.2021 11:49, Juergen Gross wrote:
>>> In evtchn_read() use READ_ONCE() for reading the producer index in
>>> order to avoid the compiler generating multiple accesses.
>>>
>>> Signed-off-by: Juergen Gross
>>>
flight 159123 xen-unstable running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159123/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev broken
build-arm64
flight 159111 xen-4.12-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159111/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev broken
build-amd64-x
flight 159116 linux-linus running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159116/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-arm64
flight 159122 qemu-mainline running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159122/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvopsbroken
build-armhf
flight 159125 ovmf running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159125/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3864 host-install(4)broken REGR. vs. 159040
bu
flight 159120 xen-4.11-testing running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159120/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev broken
build-amd64-p
flight 159118 libvirt running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159118/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64-pvops
flight 159113 linux-5.4 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/159113/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-arm64
On 08/02/2021 10:36, Jan Beulich wrote:
> On 08.02.2021 11:23, Andrew Cooper wrote:
>> On 08/02/2021 09:50, Jan Beulich wrote:
>>> On 08.02.2021 10:44, Andrew Cooper wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
> The ring buffer for user events is used in the local system only, so
On 08.02.21 10:48, Jan Beulich wrote:
On 06.02.2021 11:49, Juergen Gross wrote:
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
---
drivers/xen/evtchn.c | 2 +-
1 file changed, 1 insert
Hi Juergen,
On 08/02/2021 10:22, Jürgen Groß wrote:
On 08.02.21 10:54, Julien Grall wrote:
... I don't really see how the difference matter here. The idea is to
re-use what's already existing rather than trying to re-invent the
wheel with an extra lock (or whatever we can come up).
The diffe
On 08.02.2021 11:23, Andrew Cooper wrote:
> On 08/02/2021 09:50, Jan Beulich wrote:
>> On 08.02.2021 10:44, Andrew Cooper wrote:
>>> On 06/02/2021 10:49, Juergen Gross wrote:
The ring buffer for user events is used in the local system only, so
smp barriers are fine for ensuring consistenc
On 08/02/2021 10:25, Jürgen Groß wrote:
> On 08.02.21 11:23, Andrew Cooper wrote:
>> On 08/02/2021 09:50, Jan Beulich wrote:
>>> On 08.02.2021 10:44, Andrew Cooper wrote:
On 06/02/2021 10:49, Juergen Gross wrote:
> The ring buffer for user events is used in the local system only, so
>
1 - 100 of 118 matches
Mail list logo
