On 15.10.20 14:07, Jan Beulich wrote:
On 14.10.2020 13:40, Julien Grall wrote:
Hi Jan,
On 13/10/2020 15:26, Jan Beulich wrote:
On 13.10.2020 16:20, Jürgen Groß wrote:
On 13.10.20 15:58, Jan Beulich wrote:
On 12.10.2020 11:27, Juergen Gross wrote:
The queue for a fifo event is depending on
flight 155863 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155863/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
flight 155861 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155861/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 155788
build-amd64-xsm
ACPI specification contains statements describing memory marked with regular
"ACPI data" type as reclaimable by the guest. Although the guest shouldn't
really do it if it wants kexec or similar functionality to work, there
could still be ambiguities in treating these regions as potentially regular
On 15/10/2020 11:41, Jürgen Groß wrote:
> On 15.10.20 12:09, Jan Beulich wrote:
>> On 15.10.2020 09:58, Jürgen Groß wrote:
>>> After a short discussion on IRC yesterday I promised to send a mail
>>> how I think we could get rid of creating dynamic links especially
>>> for header files in the Xen
flight 155841 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155841/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 152631
flight 155869 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155869/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate fail REGR. vs.
155850
Tests which
On Thu, 15 Oct 2020, Bertrand Marquis wrote:
> > On 14 Oct 2020, at 22:15, Stefano Stabellini wrote:
> >
> > On Wed, 14 Oct 2020, Julien Grall wrote:
> >> On 14/10/2020 17:03, Bertrand Marquis wrote:
> On 14 Oct 2020, at 12:35, Andrew Cooper
> wrote:
>
> On 14/10/2020
On Wed, 14 Oct 2020, Julien Grall wrote:
> Hi Elliot,
>
> On 14/10/2020 02:37, Elliott Mitchell wrote:
> > On Tue, Oct 13, 2020 at 06:06:26PM -0700, Stefano Stabellini wrote:
> > > On Mon, 12 Oct 2020, Elliott Mitchell wrote:
> > > > I'm on different hardware, but some folks have setup Tianocore
Hi
On Thu, 15 Oct 2020 16:08:13 +0200 Christian König
wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
> > address space. The mapping's address is returned as struct dma_buf_map.
> > Each function is a
Hi
On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter wrote:
> On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
> > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in
> > > kernel address space. The mapping's
flight 155850 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155850/
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
On 15/10/2020 16:14, Jan Beulich wrote:
> On 15.10.2020 16:50, Jason Andryuk wrote:
>> On Thu, Oct 15, 2020 at 3:00 AM Jan Beulich wrote:
>>> And why is there no bounds check of ->phys_entry paralleling the
>>> ->virt_entry one?
>> What is the purpose of this checking? It's sanity checking which
On Thu, Oct 15, 2020 at 12:39 PM Tamas K Lengyel
wrote:
>
> > > Can you paste the memory map as printed by Xen when booting, and what
> > > command line are you using to boot Xen.
> >
> > So this is OpenXT, and it's booting EFI -> xen -> tboot -> xen
>
> Unrelated comment: since tboot now has a
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these fields will be used
on Arm as is. Move them to common struct vcpu as a part of new
struct vcpu_io. Also move enum hvm_io_completion to xen/sched.h
and remove "hvm" prefixes.
This patch completely removes layering violation
From: Oleksandr Tyshchenko
This patch adds basic support for configuring and assisting virtio-disk
backend (emualator) which is intended to run out of Qemu and could be run
in any domain.
Xenstore was chosen as a communication interface for the emulator running
in non-toolstack domain to be
From: Julien Grall
This patch adds basic IOREQ/DM support on Arm. The subsequent
patches will improve functionality and add remaining bits.
The IOREQ/DM features are supposed to be built with IOREQ_SERVER
option enabled, which is disabled by default on Arm for now.
Please note, the "PIO
From: Oleksandr Tyshchenko
This patch adds proper handling of return value of handle_io_completion()
which involves using a loop in leave_hypervisor_to_guest().
The reason to use an unbounded loop here is the fact that vCPU
shouldn't continue until an I/O has completed. In Xen case, if an I/O
From: Oleksandr Tyshchenko
This patch introduces a helper the main purpose of which is to check
if a domain is using IOREQ server(s).
On Arm the current benefit is to avoid calling handle_io_completion()
(which implies iterating over all possible IOREQ servers anyway)
on every return in
From: Oleksandr Tyshchenko
In order to avoid code duplication (both handle_read() and
handle_ioserv() contain the same code for the sign-extension)
put this code to a common helper to be used for both.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
Please note, this is a
From: Oleksandr Tyshchenko
We need to send mapcache invalidation request to qemu/demu everytime
the page gets removed from a guest.
At the moment, the Arm code doesn't explicitely remove the existing
mapping before inserting the new mapping. Instead, this is done
implicitely by
From: Oleksandr Tyshchenko
As the IOREQ is a common feature now and we also need to
invalidate qemu/demu mapcache on Arm when the required condition
occurs this patch moves this function to the common code
(and remames it to send_invalidate_ioreq).
This patch also moves per-domain
From: Julien Grall
This patch adds ability to the device emulator to notify otherend
(some entity running in the guest) using a SPI and implements Arm
specific bits for it. Proposed interface allows emulator to set
the logical level of a one of a domain's IRQ lines.
We can't reuse the existing
From: Oleksandr Tyshchenko
This patch implements reference counting of foreign entries in
in set_foreign_p2m_entry() on Arm. This is a mandatory action if
we want to run emulator (IOREQ server) in other than dom0 domain,
as we can't trust it to do the right thing if it is not running
in dom0. So
From: Oleksandr Tyshchenko
This patch removes "hvm" prefixes and infixes from IOREQ
related function names in the common code.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
Please note, this is a split/cleanup/hardening of Julien's PoC:
"Add support for Guest IO forwarding to a
From: Julien Grall
This patch creates specific device node in the Guest device-tree
with allocated MMIO range and SPI interrupt if specific 'virtio'
property is present in domain config.
Signed-off-by: Julien Grall
Signed-off-by: Oleksandr Tyshchenko
---
Please note, this is a
From: Oleksandr Tyshchenko
The cmpxchg() in hvm_send_buffered_ioreq() operates on memory shared
with the emulator domain (and the target domain if the legacy
interface is used).
In order to be on the safe side we need to switch
to guest_cmpxchg64() to prevent a domain to DoS Xen on Arm.
As
From: Julien Grall
As a lot of x86 code can be re-used on Arm later on, this patch
splits devicemodel support into common and arch specific parts.
The common DM feature is supposed to be built with IOREQ_SERVER
option enabled (as well as the IOREQ feature), which is selected
for x86's config
On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
> > address space. The mapping's address is returned as struct dma_buf_map.
> > Each function is a
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these structs will be used
on Arm as is. Move them to xen/ioreq.h and remove "hvm" prefixes.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
Please note, this is a split/cleanup/hardening of Julien's PoC:
"Add support
From: Oleksandr Tyshchenko
We don't want to move HVM params field out of *arch.hvm* in this particular
case as although it stores a few IOREQ params, it is not a (completely)
IOREQ stuff and is specific to the architecture. Instead, abstract
accesses by the proposed macro.
This is a follow up
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these structs will be used
on Arm as is. Move them to common struct domain. This also
significantly reduces the layering violation in the common code
(*arch.hvm* usage).
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
moves previously prepared x86/hvm/ioreq.c to the common code.
The common IOREQ feature is supposed to be built with IOREQ_SERVER
option enabled, which is selected for x86's config HVM for now.
In order
From: Julien Grall
As x86 implementation of XENMEM_resource_ioreq_server can be
re-used on Arm later on, this patch makes it common and removes
arch_acquire_resource as unneeded.
This support is going to be used on Arm to be able run device
emulator outside of Xen hypervisor.
Signed-off-by:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and Arm will have its own
implementation.
But the name of the function is pretty generic and can be confusing
on Arm (we already have a try_handle_mmio()).
In order not to rename the function (which is used for a varying
set of
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and this helper will be used
on Arm as is. Move it to xen/ioreq.h and remove "hvm" prefix.
Although PIO handling on Arm is not introduced with the current series
(it will be implemented when we add support for vPCI), technically
the
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these helpers will be used
on Arm as is. Move them to xen/ioreq.h and replace "hvm" prefixes
with "ioreq".
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
Please note, this is a split/cleanup/hardening of Julien's PoC:
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this
patch makes some preparation to x86/hvm/ioreq.c before moving
to the common code. This way we will get a verbatim copy for
a code movement in subsequent patch (arch/x86/hvm/ioreq.c
will be *just* renamed to
From: Oleksandr Tyshchenko
Hello all.
The purpose of this patch series is to add IOREQ/DM support to Xen on Arm.
You can find an initial discussion at [1] and RFC/V1 series at [2]/[3].
Xen on Arm requires some implementation to forward guest MMIO access to a device
model in order to implement
> > Can you paste the memory map as printed by Xen when booting, and what
> > command line are you using to boot Xen.
>
> So this is OpenXT, and it's booting EFI -> xen -> tboot -> xen
Unrelated comment: since tboot now has a PE build
(http://hg.code.sf.net/p/tboot/code/rev/5c68f0963a78) I think
On 15/10/2020 16:16, Jan Beulich wrote:
> On 15.10.2020 16:02, Andrew Cooper wrote:
>> On 15/10/2020 09:50, Jan Beulich wrote:
>>> On 14.10.2020 20:47, Andrew Cooper wrote:
cpu_smpboot_alloc() is designed to be idempotent with respect to partially
initialised state. This occurs for S3
The mro will now contain exactly one of "blockers" or "tolerable".
Nothing uses this yet.
Signed-off-by: Ian Jackson
---
sg-report-flight | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sg-report-flight b/sg-report-flight
index 51a409ed..fd266586 100755
---
CC: Andrew Cooper
Signed-off-by: Ian Jackson
---
cr-daily-branch | 1 +
1 file changed, 1 insertion(+)
diff --git a/cr-daily-branch b/cr-daily-branch
index 3e58d465..9b1961bd 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -484,6 +484,7 @@ default_immediate_retry=$wantpush
case
Do not do a retest if it would involve retesting more than 10% of the
original flight, or if it wouldn't get a push even if the retests
pass.
Signed-off-by: Ian Jackson
---
cr-daily-branch | 15 +++
1 file changed, 15 insertions(+)
diff --git a/cr-daily-branch b/cr-daily-branch
From: Ian Jackson
We exclude the self-tests because we don't want to miss breakage, and
the Xen smoke tests because they will be run again RSN anyway.
Signed-off-by: Ian Jackson
---
cr-daily-branch | 48 +++-
1 file changed, 47 insertions(+), 1
This is primarily useful for debugging the immediate-retry logic, but
it seems churlish to delete it again.
Signed-off-by: Ian Jackson
---
cr-daily-branch | 4
1 file changed, 4 insertions(+)
diff --git a/cr-daily-branch b/cr-daily-branch
index bea8734e..3e58d465 100755
---
This is only used in report_flight. We are going to want to call
report_flight from outside start_email, without having to set that
variable ourselves.
The variable isn't actually used in start_email.
Signed-off-by: Ian Jackson
---
cri-args-hostlists | 2 +-
1 file changed, 1 insertion(+), 1
Sort the flight summary lines together, before the URLs. This makes
it considerably easier to read.
Signed-off-by: Ian Jackson
---
sg-report-flight | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/sg-report-flight b/sg-report-flight
index
From: Ian Jackson
Nothing produces this yet. (There's play-retry as well of course but
we don't need to document that really.)
Signed-off-by: Ian Jackson
---
README.dev | 9 +
cr-daily-branch | 3 ++-
cr-disk-report | 2 +-
cr-try-bisect | 4 ++--
$anypassq is used for the "never pass" check; the distinction between
this and simply "fail" is cosmetic (although it can be informative).
On non-"real" flights, it can easily happen that the flight never
passed *on this branch with this blessing* but has passed on real. So
the steps subquery
From: Ian Jackson
Put the call to this debugging/testing variable inside an eval. This
allows a wider variety of stunts. The one in-tree reference is
already compatible with this new semantics.
Signed-off-by: Ian Jackson
---
cr-daily-branch | 2 +-
1 file changed, 1 insertion(+), 1
This is a Tcl list of globs for ., and allows for
simulating particular test failures.
Signed-off-by: Ian Jackson
---
sg-run-job | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/sg-run-job b/sg-run-job
index dd76d4f2..c64ae026 100755
--- a/sg-run-job
+++ b/sg-run-job
From: Ian Jackson
No effect if this is empty.
Signed-off-by: Ian Jackson
---
cri-args-hostlists | 1 +
1 file changed, 1 insertion(+)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index 6cdff53f..7019c0c7 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@ -121,6 +121,7 @@
Signed-off-by: Ian Jackson
---
cri-args-hostlists | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index 994e00c0..6cdff53f 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@ -68,8 +68,8 @@ fi
execute_flight () {
From: Ian Jackson
This just generates an extra heading and URL at the top of the output.
In particular, it doesn't affect the algorithms which calculate
regressions.
Signed-off-by: Ian Jackson
---
sg-report-flight | 18 ++
1 file changed, 18 insertions(+)
diff --git
We discussed this at the Xen Summit. What I do here is immediate
retry the jobs with regressions, and then reanalyse the original full
flight. If the retries showed the failures were heisenbugs, this will
let them though.
This should reduce the negative impact on development, of heisenbugs,
but
From: Ian Jackson
No functional change.
Signed-off-by: Ian Jackson
---
sg-report-flight | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/sg-report-flight b/sg-report-flight
index 15631001..2ab1637f 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@
From: Ian Jackson
NFC.
Signed-off-by: Ian Jackson
---
cri-args-hostlists | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index 7019c0c7..52e39f33 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@
These are large and not very useful. A copy is in the tree if needed.
Signed-off-by: Ian Jackson
---
mg-execute-flight | 3 ---
1 file changed, 3 deletions(-)
diff --git a/mg-execute-flight b/mg-execute-flight
index 391f4810..bef8dab6 100755
--- a/mg-execute-flight
+++ b/mg-execute-flight
@@
On Thu, Oct 15, 2020 at 03:24:34PM +, osstest service owner wrote:
> flight 155829 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/155829/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
flight 155832 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155832/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 12 debian-install fail REGR. vs. 155788
build-amd64-xsm
flight 155829 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155829/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
On Thu, Oct 15, 2020 at 7:31 AM Roger Pau Monné wrote:
>
> On Wed, Oct 14, 2020 at 08:37:06PM +0100, Andrew Cooper wrote:
> > On 14/10/2020 20:28, Jason Andryuk wrote:
> > > Hi,
> > >
> > > Bug opened at https://gitlab.freedesktop.org/drm/intel/-/issues/2576
> > >
> > > I'm seeing DMA faults for
On 15.10.2020 16:02, Andrew Cooper wrote:
> On 15/10/2020 09:50, Jan Beulich wrote:
>> On 14.10.2020 20:47, Andrew Cooper wrote:
>>> cpu_smpboot_alloc() is designed to be idempotent with respect to partially
>>> initialised state. This occurs for S3 and CPU parking, where enough state
>>> to
>>>
On 15.10.2020 16:50, Jason Andryuk wrote:
> On Thu, Oct 15, 2020 at 3:00 AM Jan Beulich wrote:
>> And why is there no bounds check of ->phys_entry paralleling the
>> ->virt_entry one?
>
> What is the purpose of this checking? It's sanity checking which is
> generally good, but what is the harm
On Thu, 15 Oct 2020 16:24:15 +0200 Roger Pau Monne wrote:
> Assume that reads and writes to the variable will be atomic. The worse
> that could happen is that one of the LRU intervals is not calculated
> properly if a partially written value is read, but that would only be
> a transient issue.
>
On Thu, Oct 15, 2020 at 05:02:21PM +0200, Jan Beulich wrote:
> On 15.10.2020 16:59, Jason Andryuk wrote:
> > On Thu, Oct 15, 2020 at 4:10 AM Jan Beulich wrote:
> >>
> >> On 14.10.2020 19:53, Jason Andryuk wrote:
> >>> @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
> >>> Enabling this option may
On Thu, Oct 15, 2020 at 09:00:09AM +0200, Jan Beulich wrote:
> On 14.10.2020 18:27, Jason Andryuk wrote:
> > On Wed, Oct 14, 2020 at 12:02 PM Jan Beulich wrote:
> >>
> >> On 14.10.2020 17:31, Jason Andryuk wrote:
> >>> Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
> >>>
On 15.10.2020 16:59, Jason Andryuk wrote:
> On Thu, Oct 15, 2020 at 4:10 AM Jan Beulich wrote:
>>
>> On 14.10.2020 19:53, Jason Andryuk wrote:
>>> @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
>>> Enabling this option may incur a significant performance overhead.
>>>
>>> config XEN_PVH
>>> -
flight 155839 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155839/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 155770
test-amd64-amd64-xl-qemuu-ws16-amd64 19
On Thu, Oct 15, 2020 at 4:10 AM Jan Beulich wrote:
>
> On 14.10.2020 19:53, Jason Andryuk wrote:
> > @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
> > Enabling this option may incur a significant performance overhead.
> >
> > config XEN_PVH
> > - bool "Support for running as a Xen PVH guest"
On Thu, Oct 15, 2020 at 5:42 AM Jürgen Groß wrote:
>
> On 14.10.20 19:53, Jason Andryuk wrote:
> > Moving XEN_512GB allows it to nest under XEN_PV. That also allows
> > XEN_PVH to nest under XEN as a sibling to XEN_PV and XEN_PVHVM giving:
> >
> > [*] Xen guest support
> > [*] Xen PV guest
On Thu, Oct 15, 2020 at 9:17 AM wrote:
>
>
> On 10/15/20 9:10 AM, Andrew Cooper wrote:
> > On 15/10/2020 13:37, boris.ostrov...@oracle.com wrote:
> >> On 10/14/20 1:53 PM, Jason Andryuk wrote:
> >>> +config XEN_512GB
> >>> + bool "Limit Xen pv-domain memory to 512GB"
> >>> + depends on XEN_PV
On Thu, Oct 15, 2020 at 3:00 AM Jan Beulich wrote:
>
> On 14.10.2020 18:27, Jason Andryuk wrote:
> > On Wed, Oct 14, 2020 at 12:02 PM Jan Beulich wrote:
> >>
> >> On 14.10.2020 17:31, Jason Andryuk wrote:
> >>> Linux kernels only have an ENTRY elfnote when built with CONFIG_PV. A
> >>> kernel
On Thu, Oct 15, 2020 at 04:37:52PM +0200, Jürgen Groß wrote:
> On 15.10.20 16:24, Roger Pau Monne wrote:
> > Assume that reads and writes to the variable will be atomic. The worse
> > that could happen is that one of the purges removes a partially
> > written percentage of grants, but the cache
On 15.10.20 16:24, Roger Pau Monne wrote:
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the purges removes a partially
written percentage of grants, but the cache itself will recover.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad
flight 155837 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155837/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 19c87b7d446c3273e84b238cb02cd1c0ae69c43e
baseline version:
ovmf
On 15.10.20 16:24, Roger Pau Monne wrote:
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the LRU intervals is not calculated
properly if a partially written value is read, but that would only be
a transient issue.
Signed-off-by: Roger Pau
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the LRU intervals is not calculated
properly if a partially written value is read, but that would only be
a transient issue.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc:
Add the LRU parameters as tunables.
Roger Pau Monne (2):
xen/blkback: turn the cache purge LRU interval into a parameter
xen/blkback: turn the cache purge percent into a parameter
.../ABI/testing/sysfs-driver-xen-blkback | 19 +++
drivers/block/xen-blkback/blkback.c
Assume that reads and writes to the variable will be atomic. The worse
that could happen is that one of the purges removes a partially
written percentage of grants, but the cache itself will recover.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Jens Axboe
Cc: Boris
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's
On 15/10/2020 09:50, Jan Beulich wrote:
> On 14.10.2020 20:47, Andrew Cooper wrote:
>> cpu_smpboot_alloc() is designed to be idempotent with respect to partially
>> initialised state. This occurs for S3 and CPU parking, where enough state to
>> handle NMIs/#MCs needs to remain valid for the
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by:
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
flight 155842 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155842/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 155828
Tests which
On Wed, Oct 07, 2020 at 06:41:17PM +0200, Roger Pau Monné wrote:
> On Wed, Oct 07, 2020 at 01:06:08PM +0100, Andrew Cooper wrote:
> > On 06/10/2020 17:23, Roger Pau Monne wrote:
> > > Currently a PV hardware domain can also be given control over the CPU
> > > frequency, and such guest is allowed
On 10/15/20 9:10 AM, Andrew Cooper wrote:
> On 15/10/2020 13:37, boris.ostrov...@oracle.com wrote:
>> On 10/14/20 1:53 PM, Jason Andryuk wrote:
>>> +config XEN_512GB
>>> + bool "Limit Xen pv-domain memory to 512GB"
>>> + depends on XEN_PV && X86_64
>> Why is X86_64 needed here?
>> 512G
Jan Beulich writes ("[PATCH] tools/gdbsx: drop stray recursion into
tools/include/"):
> Doing so isn't appropriate here - this gets done very early in the build
> process. If the directory is mean to to be buildable on its own,
> different arrangements would be needed.
>
> The issue has become
On 15/10/2020 13:37, boris.ostrov...@oracle.com wrote:
> On 10/14/20 1:53 PM, Jason Andryuk wrote:
>> +config XEN_512GB
>> +bool "Limit Xen pv-domain memory to 512GB"
>> +depends on XEN_PV && X86_64
>
> Why is X86_64 needed here?
>512G support was implemented using a direct-mapped P2M,
On Thu, Oct 15, 2020 at 02:53:34PM +0200, J. Roeleveld wrote:
> On Thursday, October 15, 2020 2:00:46 PM CEST Roger Pau Monné wrote:
> > Please don't drop xen-devel mailing list when replying.
>
> My apologies, most mailing lists I am active on have a working "reply"
> button.
> Here I need to
flight 155831 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155831/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On Thursday, October 15, 2020 2:00:46 PM CEST Roger Pau Monné wrote:
> Please don't drop xen-devel mailing list when replying.
My apologies, most mailing lists I am active on have a working "reply" button.
Here I need to use "reply-all".
> On Thu, Oct 15, 2020 at 01:28:49PM +0200, J. Roeleveld
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
Signed-off-by: Thomas Zimmermann
---
include/linux/dma-buf-map.h | 72 +++--
1 file changed, 62 insertions(+), 10 deletions(-)
On 10/14/20 1:53 PM, Jason Andryuk wrote:
> +config XEN_512GB
> + bool "Limit Xen pv-domain memory to 512GB"
> + depends on XEN_PV && X86_64
Why is X86_64 needed here?
-boris
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 1 -
1 - 100 of 139 matches
Mail list logo
