flight 149696 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149696/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
Fix the following sparse warning:
arch/x86/pci/xen.c:426:13: warning: symbol 'xen_msi_init' was not
declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
arch/x86/pci/xen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/pci/xen.c b/ar
On 16.04.2020 17:09, Anthony PERARD wrote:
> On Thu, Apr 16, 2020 at 04:22:05PM +0200, Jan Beulich wrote:
>> On 16.04.2020 14:44, Anthony PERARD wrote:
>>> On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
On 31.03.2020 12:30, Anthony PERARD wrote:
> We want to use the same rune
In order to easily translate CPU cycles to time values add the
following helpers:
- cycles2nsec()
- cycles2usec()
- cycles2msec()
Signed-off-by: Pawel Wieczorkiewicz
---
common/time.c | 17 +
include/xtf/time.h | 5 -
2 files changed, 21 insertions(+), 1 deletion(-)
di
This is a 2nd attempt to contribute time management functionality
to XTF. It is also a 2nd batch of the changes I want to sent upstream.
The patches add common/time.c core with scaling and system time
calculating functions.
Other patches add helper functions based on the core functionality.
Final
From: Paul Semel
This commit introduces basic time management functionality.
For synchronization purpose, we do really want to be able to
"control" time.
Add since_boot_time() that gets the time in nanoseconds from the
moment the VM has booted.
Signed-off-by: Paul Semel
Signed-off-by: Pawel Wi
From: Paul Semel
Signed-off-by: Paul Semel
---
common/time.c | 14 ++
include/xtf/time.h | 12
2 files changed, 26 insertions(+)
diff --git a/common/time.c b/common/time.c
index 7decd07..fffae1c 100644
--- a/common/time.c
+++ b/common/time.c
@@ -90,6 +90,20 @@ uin
From: Paul Semel
Add the following helper functions:
- nspin_sleep()
- spin_sleep()
- mspin_sleep()
Add the following helper macros:
- sleep()
- msleep()
- NOW()
Signed-off-by: Paul Semel
---
common/time.c | 58 ++
include/x
Signed-off-by: Pawel Wieczorkiewicz
---
include/xen/event_channel.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/xen/event_channel.h b/include/xen/event_channel.h
index 62ee95a..6253b89 100644
--- a/include/xen/event_channel.h
+++ b/include/xen/event_channel.h
@@ -2,6 +2,7 @
From: Paul Semel
This function returns the "epoch" time.
Signed-off-by: Paul Semel
---
common/time.c | 16
include/xtf/time.h | 4
2 files changed, 20 insertions(+)
diff --git a/common/time.c b/common/time.c
index b9a6531..7decd07 100644
--- a/common/time.c
+++ b/c
flight 149693 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149693/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail like 149659
test-amd64-amd64-xl-rtds 18 guest
flight 149694 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149694/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a7947b6366a660d4d655371fe6bc96315097c06d
baseline version:
ovmf 06033f5abad3815e8d80d
On 16.04.20 18:47, Dario Faggioli wrote:
On Thu, 2020-04-16 at 11:25 +0200, Jürgen Groß wrote:
On 16.04.20 11:20, Sergey Dyasli wrote:
On 16/04/2020 09:57, Jürgen Groß wrote:
The xen commandline ins part of the boot messages and is
contained
in the "xl info" output.
It's true that you can s
On 16.04.20 18:43, Dario Faggioli wrote:
On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:
Currently it might be not obvious which scheduling mode is being used
by the scheduler. Alleviate this by printing additional information
about the selected granularity.
I like the idea. However, I
Hi Jan,
On 16/04/2020 16:46, Jan Beulich wrote:
While it should have been this way from the beginning, not doing so will
become an actual problem with PVH Dom0.
I think the current code is also buggy on PV dom0 because the buffer is
not locked in memory. So you have no promise the buffer will
*** TWO WEEKS UNTIL LAST POSTING ***
This email only tracks big items for xen.git tree. Please reply for items
you would like to see in 4.14 so that people have an idea what
is going on and prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working o
On 17.03.2020 16:23, Jason Andryuk wrote:
> Below is the diff. It was messier and I tidied it up some.
I've looked into this some more. I can see how what we currently
do is not in line with firmware handing off with LegacyReplacement
mode enabled. However, this case doesn't look to apply here:
On 17.04.2020 11:10, Paul Durrant wrote:
> * Memory read caching in emulation (v5)
> - Jan Beulich
I'd like to take this as an opportunity to ask on the disposition
of this series: Under the new rules in principle I could have put
this in with Paul's R-b, but given the prior discussions I didn
On 17.04.2020 10:37, Julien Grall wrote:
> On 16/04/2020 16:46, Jan Beulich wrote:
>> While it should have been this way from the beginning, not doing so will
>> become an actual problem with PVH Dom0.
>
> I think the current code is also buggy on PV dom0 because the buffer
> is not locked in memo
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/x86_64/mm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 18210405f4..5714e5ba62 100644
--- a/xen/arch/x86/x86_64/mm.c
+
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/smpboot.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 09264b02d1..275ce7661d 100644
--- a/xen/arch/x86/smpbo
From: Hongyan Xia
Basically just rewriting functions using the new API to map and unmap
PTEs. Each patch is independent.
Apart from mapping and unmapping page tables, no other functional change
intended.
Wei Liu (6):
x86_64/mm: map and unmap page tables in cleanup_frame_table
x86_64/mm: map
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/x86_64/mm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 5714e5ba62..6d52183559 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xe
From: Wei Liu
Also fix a weird indentation.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/x86_64/mm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index e85ef449f3..18210405f4 100644
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/pv/dom0_build.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 28a939b68a..a03f0501ab 100644
--- a/xen/arch/x86/pv/dom0_b
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/pv/dom0_build.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c
index 5678da782d..28a939b68a 10064
On 15.04.2020 03:02, Stefano Stabellini wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -911,54 +911,18 @@ static struct page_info *get_free_buddy(unsigned int
> zone_lo,
> }
> }
>
> -/* Allocate 2^@order contiguous pages. */
> -static struct page_info *alloc_he
On 15.04.2020 03:02, Stefano Stabellini wrote:
> Introduce a function named reserve_heap_pages (similar to
> alloc_heap_pages) that allocates a requested memory range. Call
> __alloc_heap_pages for the implementation.
>
> Change __alloc_heap_pages so that the original page doesn't get
> modified,
The EPT page tables can be shared with the IOMMU as long as the page
sizes supported by EPT are also supported by the IOMMU.
Current code checks that both the IOMMU and EPT support the same page
sizes, but this is not strictly required, the IOMMU supporting more
page sizes than EPT is fine and sho
On 17.04.2020 12:26, Roger Pau Monne wrote:
> The EPT page tables can be shared with the IOMMU as long as the page
> sizes supported by EPT are also supported by the IOMMU.
>
> Current code checks that both the IOMMU and EPT support the same page
> sizes, but this is not strictly required, the IOM
On Fri, Apr 17, 2020 at 12:57:16PM +0200, Jan Beulich wrote:
> On 17.04.2020 12:26, Roger Pau Monne wrote:
> > The EPT page tables can be shared with the IOMMU as long as the page
> > sizes supported by EPT are also supported by the IOMMU.
> >
> > Current code checks that both the IOMMU and EPT su
flight 149699 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149699/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
The EPT page tables can be shared with the IOMMU as long as the page
sizes supported by EPT are also supported by the IOMMU.
Current code checks that both the IOMMU and EPT support the same page
sizes, but this is not strictly required, the IOMMU supporting more
page sizes than EPT is fine and sho
... in accordance with the timeline layed out in the Kconfig message. There
has been no comment since it was disabled by default.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/Kconfig| 23 ---
xen/arch/x8
On Fri, Apr 17, 2020 at 12:34:23PM +0100, Andrew Cooper wrote:
> ... in accordance with the timeline layed out in the Kconfig message. There
> has been no comment since it was disabled by default.
layed -> laid
Code looks good to me:
Reviewed-by: Wei Liu
On 17.04.2020 13:16, Roger Pau Monné wrote:
> On Fri, Apr 17, 2020 at 12:57:16PM +0200, Jan Beulich wrote:
>> On 17.04.2020 12:26, Roger Pau Monne wrote:
>>> --- a/xen/drivers/passthrough/vtd/iommu.c
>>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>>> @@ -1914,8 +1914,10 @@ static int __init vtd_ept_
On 17.04.2020 13:29, Roger Pau Monne wrote:
> The EPT page tables can be shared with the IOMMU as long as the page
> sizes supported by EPT are also supported by the IOMMU.
>
> Current code checks that both the IOMMU and EPT support the same page
> sizes, but this is not strictly required, the IOM
On Fri, Apr 17, 2020 at 09:12:11AM +0200, Jan Beulich wrote:
> On 16.04.2020 17:09, Anthony PERARD wrote:
> > On Thu, Apr 16, 2020 at 04:22:05PM +0200, Jan Beulich wrote:
> >> On 16.04.2020 14:44, Anthony PERARD wrote:
> >>> On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote:
> On 31.
flight 149695 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149695/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 149689
test-amd64-i386-xl-qemut-win7-amd64
On 17.04.2020 15:19, Anthony PERARD wrote:
> On Fri, Apr 17, 2020 at 09:12:11AM +0200, Jan Beulich wrote:
>> On 16.04.2020 17:09, Anthony PERARD wrote:
>>> On Thu, Apr 16, 2020 at 04:22:05PM +0200, Jan Beulich wrote:
On 16.04.2020 14:44, Anthony PERARD wrote:
> On Wed, Apr 08, 2020 at 02:5
From: Brendan Kerrigan
The Intel IOMMU for at least 8th and 9th generation Core processors has a bug
where the Fault Processing Disable bit is not respected for the Intel Graphics
Device (IGD). The resulting behavior was reported previously[1]. The underlying
cause is described by Intel as Errata
From: Brendan Kerrigan
The Intel graphics device records DMAR faults regardless
of the Fault Process Disable bit being set. When this fault
occurs, enable the Interrupt Mask (IM) bit in the Fault
Event Control (FECTL) register to prevent the continued
recording of the fault.
Signed-off-by: Brend
On 17/04/2020 08:57, Jürgen Groß wrote:
> On 16.04.20 18:43, Dario Faggioli wrote:
>> On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:
>>> Currently it might be not obvious which scheduling mode is being used
>>> by the scheduler. Alleviate this by printing additional information
>>> about t
On 17.04.20 15:43, Sergey Dyasli wrote:
On 17/04/2020 08:57, Jürgen Groß wrote:
On 16.04.20 18:43, Dario Faggioli wrote:
On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:
Currently it might be not obvious which scheduling mode is being used
by the scheduler. Alleviate this by printing ad
flight 149698 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149698/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c884b23ac40a1b1f56e21ebbb1f602fa2e0f05c9
baseline version:
ovmf a7947b6366a660d4d6553
Large parts of this series are to further isolate pieces which
are needed for HVM only, and hence would better not be built
with HVM=n. But there are also a few other items which I've
noticed along the road.
01: mm: no-one passes a NULL domain to init_xen_l4_slots()
02: shadow: drop a stray forwar
Drop the NULL checks - they've been introduced by commit 8d7b633ada
("x86/mm: Consolidate all Xen L4 slot writing into
init_xen_l4_slots()") for no apparent reason.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1696,7 +1696,7 @@ void init_xen_l4_slots(l4_pgentry_
struct sh_emulate_ctxt is private to shadow code, and hence a
declaration for it is not needed here.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/paging.h
+++ b/xen/include/asm-x86/paging.h
@@ -92,7 +92,6 @@
* These shouldn't be used directly by callers; rather use the functions
* be
Consolidate the shadow_mode_external() in here: Check this once at the
start of the function.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3707,34 +3707,30 @@ sh_update_linear_entries(struct vcpu *v)
*/
/* Don't try to upda
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2376,7 +2376,6 @@ void sh_reset_l3_up_pointers(struct vcpu
static void sh_update_paging_modes(struct vcpu *v)
{
struct domain *d = v->domain;
-const struct paging_mode *old_mode =
It's only used by common.c.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -38,6 +38,9 @@
#include
#include "private.h"
+static int sh_remove_write_access_from_sl1p(struct domain *d, mfn_t gmfn,
+
Move the per-vCPU field to the HVM sub-structure.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -545,7 +545,7 @@ void write_ptbase(struct vcpu *v)
* Should be called after CR3 is updated.
*
* Uses values found in vcpu->arch.(guest_table and guest_table_user)
Its only caller lives in HVM-only code.
This involves wider changes, in order to limit #ifdef-ary: Shadow's
SHOPT_FAST_EMULATION and the fields used by it get constrained to HVM
builds as well. Additionally the shadow_{init,continue}_emulation()
stubs for the !HVM case aren't needed anymore and he
sh_remove_write_access() bails early for !external guests, and hence its
building and thus the need for the hook can be suppressed altogether in
!HVM configs.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1769,6 +1769,7 @@ static inlin
Its only caller lives in HVM-only code, and the only caller of
trace_shadow_emulate() also already site in a HVM-only code section.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2694,6 +2694,7 @@ static inline void trace_shadow_emulate_
Make shadow_blow_all_tables() call the designated function, and this
occasion make the function itself use domain_vcpu().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1005,7 +1005,8 @@ static void shadow_blow_tables(struct do
void
On Fri, 2020-04-17 at 09:57 +0200, Jürgen Groß wrote:
> On 16.04.20 18:43, Dario Faggioli wrote:
> > On Thu, 2020-04-16 at 09:33 +0100, Sergey Dyasli wrote:
> > >
> > > +char *sched_gran_str(char *str, size_t size)
> > > +{
> > > +char *mode = "";
> > > +
> > > +switch ( opt_sched_granular
On Fri, 2020-04-17 at 15:52 +0200, Jürgen Groß wrote:
> On 17.04.20 15:43, Sergey Dyasli wrote:
> > While "sched-gran=core smt=0" gives:
> > (XEN) [ 259.337588] Scheduler: SMP Credit Scheduler (credit) in 1-
> > way core-scheduling mode
>
> You might want to consider not using the global variable
On Fri, Apr 17, 2020 at 03:39:48PM +0200, Jan Beulich wrote:
> On 17.04.2020 15:19, Anthony PERARD wrote:
> > Or do you mean keeping exception to the rule? And hope that when someone
> > changes the rule, it doesn't forget to check if the exception needs
> > changing as well?
>
> ... "exception" l
On 9 Apr 2020, at 14:00, Julien Grall mailto:jul...@xen.org>>
wrote:
On 09/04/2020 13:56, Julien Grall wrote:
On 09/04/2020 02:26, Stefano Stabellini wrote:
On Tue, 7 Apr 2020, Julien Grall wrote:
I don’t know what maintenance IRQs are, but if they only happen
intermittently, it’s possible tha
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.7-rc2-tag
xen: branch for v5.7-rc2
It contains:
- a small cleanup patch
- a security fix for a bug in the Xen hypervisor to avoid enabling Xen
guests to crash dom0 on an unfixed hy
Downstreams may want this for either security or performance reasons. Offer
some options, and take advantage of some of the very low hanging fruit it
offers.
There is plenty more incremental cleanup which can be done at a later point.
Andrew Cooper (3):
x86/pv: Options to disable and/or compil
There is no need for the Compat GDT if there are no 32bit PV guests. This
saves 4k per online CPU
Bloat-o-meter reports the following savings in Xen itself:
add/remove: 0/3 grow/shrink: 1/4 up/down: 7/-4612 (-4605)
Function old new delta
cpu_smpboo
This is the start of some performance and security-hardening improvements,
based on the fact that 32bit PV guests are few and far between these days.
Ring1 is full or architectural corner cases, such as counting as supervisor
from a paging point of view. This accounts for a substantial performanc
... and move arch.is_32bit_pv into the pv union while at it.
Bloat-o-meter reports the following net savings with some notable differences
highlighted:
add/remove: 4/6 grow/shrink: 5/76 up/down: 1955/-18792 (-16837)
Function old new delta
...
pv_v
Hi Bertrand,
On 17/04/2020 16:16, Bertrand Marquis wrote:
It seems that the problem is a bit bigger then expected and will need
more discussion and thinking.
I did some research on my side and there are several design possible
depending on what should be the goal performance or real-time behavi
flight 149697 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149697/
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. 149693
Regressions which a
On Fri, 17 Apr 2020, Julien Grall wrote:
> Hi Bertrand,
>
> On 17/04/2020 16:16, Bertrand Marquis wrote:
> > It seems that the problem is a bit bigger then expected and will need more
> > discussion and thinking.
> > I did some research on my side and there are several design possible
> > dependin
On 17/04/2020 17:31, Stefano Stabellini wrote:
On Fri, 17 Apr 2020, Julien Grall wrote:
Hi Bertrand,
On 17/04/2020 16:16, Bertrand Marquis wrote:
It seems that the problem is a bit bigger then expected and will need more
discussion and thinking.
I did some research on my side and there are
When a forked VM is being reset while having vm_events active, re-copying the
vCPU info page can lead to events being lost. This seems to only affect a
subset of events (interrupts), while not others (cpuid, MTF, EPT) thus it was
not discovered beforehand. Only copying vCPU info page contents durin
The following patches are part of the series that implement VM forking for
Intel HVM guests to allow for the fast creation of identical VMs without the
assosciated high startup costs of booting or restoring the VM from a savefile.
JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
The for
The memory sharing subsystem by default doesn't allow a domain to share memory
if it has an IOMMU active for obvious security reasons. However, when fuzzing a
VM fork, the same security restrictions don't necessarily apply. While it makes
no sense to try to create a full fork of a VM that has an IO
Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.
Signed-off-by: Tamas K Lengyel
---
doc
Hi Jan,
On 17/04/2020 10:44, Jan Beulich wrote:
On 17.04.2020 10:37, Julien Grall wrote:
On 16/04/2020 16:46, Jan Beulich wrote:
While it should have been this way from the beginning, not doing so will
become an actual problem with PVH Dom0.
I think the current code is also buggy on PV dom0
Hi Jan,
On 16/04/2020 13:19, Jan Beulich wrote:
On 16.04.2020 13:24, Julien Grall wrote:
From: Julien Grall
At the moment, *copy_to_guest_offset() will allow the hypervisor to copy
data to guest handle marked const.
Thankfully, no users of the helper will do that. Rather than hoping this
can
flight 149700 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149700/
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. 149637
Tests which did not s
The pull request you sent on Fri, 17 Apr 2020 17:17:35 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.7-rc2-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d0a4ebe7d1c5970f00cca09cbdfcb8ae1658349d
Thank you!
--
Deet-doot-dot, I
On 4/12/20 5:09 PM, Philippe Mathieu-Daudé wrote:
> diff --git a/hw/ide/piix.c b/hw/ide/piix.c
> index 3b2de4c312..b402a93636 100644
> --- a/hw/ide/piix.c
> +++ b/hw/ide/piix.c
> @@ -193,7 +193,7 @@ int pci_piix3_xen_ide_unplug(DeviceState *dev, bool aux)
> blk_unref(blk);
>
On 4/12/20 5:09 PM, Philippe Mathieu-Daudé wrote:
> -memory_region_init_io(&a->mmio, OBJECT(obj), &allwinner_ahci_mem_ops, a,
> +memory_region_init_io(&a->mmio, obj, &allwinner_ahci_mem_ops, a,
Acked-by: John Snow
On 17/04/2020 15:25, Jan Beulich wrote:
> Drop the NULL checks - they've been introduced by commit 8d7b633ada
> ("x86/mm: Consolidate all Xen L4 slot writing into
> init_xen_l4_slots()") for no apparent reason.
:) I'll take this as conformation that all my sudden pagetable work in
Xen manage ended
On 17/04/2020 15:26, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -2376,7 +2376,6 @@ void sh_reset_l3_up_pointers(struct vcpu
> static void sh_update_paging_modes(struct vcpu *v)
> {
> struct domain *d
On 17/04/2020 15:23, Jan Beulich wrote:
> Large parts of this series are to further isolate pieces which
> are needed for HVM only, and hence would better not be built
> with HVM=n. But there are also a few other items which I've
> noticed along the road.
>
> 01: mm: no-one passes a NULL domain to
From: Peng Fan
The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
(See https://marc.info/?l=xen-devel&m=158527653730795 for a discussion on
what it would take to implement GICD_ISACTIVER/GICD_ICACTIVER properly.)
Signed-off-by: Peng Fan
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefan
Create a new document under docs/process to describe our special tags.
Add a description of the Fixes tag and the new Backport tag. Also
clarify that lines with tags should not be split.
Signed-off-by: Stefano Stabellini
CC: Ian Jackson
CC: Wei Liu
CC: jbeul...@suse.com
CC: george.dun...@citrix
flight 149701 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149701/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
test-amd64-i386-xl
Hi,
The title claim this is a resend, but this is actually not the latest
version of this patch. Can you explain why you decided to use v1
rather than v2?
On Fri, 17 Apr 2020 at 23:16, Stefano Stabellini wrote:
>
> From: Peng Fan
>
> The end should be GICD_ISACTIVERN not GICD_ISACTIVER.
>
> (Se
On Fri, 17 Apr 2020, Julien Grall wrote:
> Hi,
>
> The title claim this is a resend, but this is actually not the latest
> version of this patch. Can you explain why you decided to use v1
> rather than v2?
Because v2 added a printk for every read, and I thought you only wanted
the range fix. Also
flight 149702 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149702/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt broken
test-amd64-i386-libv
88 matches
Mail list logo
