flight 149786 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149786/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR.
flight 149797 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149797/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 149784
Tests which
flight 149791 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149791/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 149784
Tests which
flight 149783 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149783/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine 4 memdisk-try-append fail pass in 149771
Tests which did not succeed,
On Fri, 24 Apr 2020 at 21:29, Andrei Cherechesu
wrote:
>
> Hello,
Hi,
Please don't post using HTML and instead configure your client to use
plain text.
> Do you have any idea why this occurs? Have I misconfigured anything?
OOPS should never occur because something has been misconfigured. The
On Fri, Apr 24, 2020 at 7:26 AM George Dunlap wrote:
>
>
>
> > On Apr 24, 2020, at 5:04 AM, Nick Rosbrook wrote:
> >
> > On Thu, Apr 23, 2020 at 1:22 PM George Dunlap
> > wrote:
> >>
> >>
> >>> On Apr 23, 2020, at 12:49 PM, George Dunlap
> >>> wrote:
> >>>
> >>>
> >>>
> On Apr 23, 2020,
On 4/24/20 3:53 AM, osstest service owner wrote:
flight 149773 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-build
Hello,
Recently I've been trying to enable the networking in a conventional DomU (not
dom0less).
The approach I used was the one described here:
https://wiki.xen.org/wiki/Xen_Networking#Bridging.
But when I use xl to create DomU, I get a Kernel OOPS in Dom0. The setup is
still responsive
On Fri, 17 Apr 2020, Julien Grall wrote:
> 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.
> > >
> > >
flight 149785 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 149784
Tests which
flight 149772 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149772/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 149764
test-amd64-amd64-xl-qemut-win7-amd64
On 24.04.20 18:20, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 24 April 2020 17:04
To: Jürgen Groß ; Paul Durrant ;
xen-devel@lists.xenproject.org
Cc: Paul Durrant
Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
Hi,
On 24/04/2020
> -Original Message-
> From: Julien Grall
> Sent: 24 April 2020 17:04
> To: Jürgen Groß ; Paul Durrant ;
> xen-devel@lists.xenproject.org
> Cc: Paul Durrant
> Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
>
> Hi,
>
> On 24/04/2020 16:59, Jürgen Groß
> -Original Message-
>
> > * VM forking (v11)
> > - Tamas K Lengyel
>
> v17 sent recently, hypervisor side is completely merged, only the
> toolstack patch is waiting for review & merge
>
Thanks for the update.
Paul
On 24.04.2020 16:30, Anthony PERARD wrote:
> In a clean tree, both files include/config/auto.conf{,.cmd} are
> missing and older version of GNU Make complain about it:
> Makefile:103: include/config/auto.conf: No such file or directory
> Makefile:106: include/config/auto.conf.cmd: No such
Hi,
On 24/04/2020 16:59, Jürgen Groß wrote:
On 24.04.20 17:44, Julien Grall wrote:
If I extend the record and do a downgrade I'm losing the information,
too, as the old version won't read it in any case. BTW, extending the
record is no problem, as the length is stored in the header. Unknown
On 24.04.20 17:44, Julien Grall wrote:
On 24/04/2020 15:51, Jürgen Groß wrote:
On 24.04.20 16:38, Julien Grall wrote:
Hi,
On 24/04/2020 15:26, Jürgen Groß wrote:
+```
+ 0 1 2 3 4 5 6 7
octet
> * VM forking (v11)
> - Tamas K Lengyel
v17 sent recently, hypervisor side is completely merged, only the
toolstack patch is waiting for review & merge
Tamas
On 24/04/2020 15:51, Jürgen Groß wrote:
On 24.04.20 16:38, Julien Grall wrote:
Hi,
On 24/04/2020 15:26, Jürgen Groß wrote:
+```
+ 0 1 2 3 4 5 6 7 octet
++---+---+---+---+---+---+---+---+
+| type
On 24.04.20 16:38, Julien Grall wrote:
Hi,
On 24/04/2020 15:26, Jürgen Groß wrote:
+```
+ 0 1 2 3 4 5 6 7 octet
++---+---+---+---+---+---+---+---+
+| type | len |
Maximilian Heyne writes ("Re: [PATCH 0/3] Cleanup IOREQ server on exit"):
> Could someone please have a look at this patch? It solves an actual issue:
> Try soft-reset with qemu-xen-traditional and it will fail.
Thanks. I reviewed this.
qemu is in deep freeze but the changes looked correct and
Hi,
On 24/04/2020 15:26, Jürgen Groß wrote:
+```
+ 0 1 2 3 4 5 6 7 octet
++---+---+---+---+---+---+---+---+
+| type | len |
In a clean tree, both files include/config/auto.conf{,.cmd} are
missing and older version of GNU Make complain about it:
Makefile:103: include/config/auto.conf: No such file or directory
Makefile:106: include/config/auto.conf.cmd: No such file or directory
Those warnings are harmless,
On 24.04.20 15:37, Paul Durrant wrote:
From: Paul Durrant
... to specify a separate migration stream that will also be suitable for
live update.
The original scope of the document was to support non-cooperative migration
of guests [1] but, since then, live update of xenstored has been brought
From: Wei Liu
No functional change.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/mm.c| 48
xen/arch/x86/smpboot.c | 12 +-
xen/arch/x86/x86_64/mm.c | 10 -
xen/common/efi/boot.c| 10 -
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/efi/runtime.h | 10 +++--
xen/common/efi/boot.c | 46 ++
xen/common/efi/efi.h | 3 ++-
xen/common/efi/runtime.c | 8 +++
4 files changed, 46
From: Hongyan Xia
Two sets of old APIs, alloc/free_xen_pagetable() and lXe_to_lYe(), are
now dropped to avoid the dependency on direct map.
There are two special cases which still have not been re-written into
the new APIs, thus need special treatment:
rpt in smpboot.c cannot use ephemeral
From: Hongyan Xia
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/mm.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 749b6f23e5..7e212cc3e0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@
From: Wei Liu
We will soon need to clean up page table mappings in the exit path.
No functional change.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/smpboot.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/smpboot.c
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/smpboot.c | 54 +++---
1 file changed, 35 insertions(+), 19 deletions(-)
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 5b0e24f925..0e0ae56c76 100644
---
From: Wei Liu
We will soon need to handle dynamically mapping / unmapping page
tables in the said function. Since dynamic mappings may map and unmap
pl3e in different iterations, lift pl3e out of the loop.
No functional change.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
Changed
From: Wei Liu
After inspection ARM doesn't have alloc_xen_pagetable so this function
is x86 only, which means it is safe for us to change.
Signed-off-by: Wei Liu
---
xen/common/efi/boot.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/xen/common/efi/boot.c
From: Wei Liu
Page tables allocated in that function should be mapped and unmapped
now.
Note that pl2e now maybe mapped and unmapped in different iterations, so
we need to add clean-ups for that.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/mm.c | 57
From: Wei Liu
Also reduce the scope of l2_ro_mpt as it is only used inside the loop,
and remove two lines of l2_ro_mpt check which serve no purpose.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/x86_64/mm.c | 24 +---
1 file changed, 13 insertions(+),
From: Hongyan Xia
This series rewrites all the remaining functions and finally makes the
switch from xenheap to domheap for Xen page tables, so that they no
longer need to rely on the direct map, which is a big step towards
removing the direct map.
This series depends on the following two
From: Wei Liu
Page tables allocated in that function should be mapped and unmapped
now.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/mm.c | 60 ---
1 file changed, 36 insertions(+), 24 deletions(-)
diff --git
From: Wei Liu
Introduce pl2e so that we can use l2_ro_mpt to point to the page table
itself.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/x86_64/mm.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c
From: Wei Liu
Rewrite those functions to use the new APIs. Modify its callers to unmap
the pointer returned.
Note that the change of virt_to_xen_l1e() also requires vmap_to_mfn() to
unmap the page, which requires domain_page.h header in vmap.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
From: Wei Liu
Map and unmap pages instead of relying on the direct map.
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
---
xen/arch/x86/x86_64/mm.c | 43
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/x86_64/mm.c
From: Wei Liu
We will soon rewrite the function to handle dynamically mapping and
unmapping of page tables. Since dynamic mappings may map and unmap pages
in different iterations of the while loop, we need to lift pl3e out of
the loop.
No functional change.
Signed-off-by: Wei Liu
On Fri, Apr 24, 2020 at 02:30:56PM +0100, Anthony PERARD wrote:
> On Fri, Apr 24, 2020 at 03:01:32PM +0200, Jan Beulich wrote:
> > While committing this, in my pre-push build test I noticed that
> > presumably an earlier change of yours has caused
> >
> > Makefile:103: include/config/auto.conf:
flight 149771 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149771/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 149741
test-amd64-i386-xl-qemut-win7-amd64
flight 149782 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149782/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
examine-albana1 4 memdisk-try-append fail blocked in 149768
examine-albana0 4
From: Paul Durrant
... to specify a separate migration stream that will also be suitable for
live update.
The original scope of the document was to support non-cooperative migration
of guests [1] but, since then, live update of xenstored has been brought into
scope. Thus it makes more sense to
On Fri, Apr 24, 2020 at 03:01:32PM +0200, Jan Beulich wrote:
> While committing this, in my pre-push build test I noticed that
> presumably an earlier change of yours has caused
>
> Makefile:103: include/config/auto.conf: No such file or directory
> Makefile:106: include/config/auto.conf.cmd: No
On 23.04.2020 17:30, Tamas K Lengyel wrote:
> 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
On 21.04.2020 18:11, Anthony PERARD wrote:
> Instead of generating the CFLAGS in Rules.mk everytime we enter a new
> subdirectory, we are going to generate most of them a single time, and
> export the result in the environment so that Rules.mk can use it. The
> only flags left to be generated are
On Fri, Apr 24, 2020 at 06:18:24AM -0600, Tamas K Lengyel wrote:
> On Fri, Apr 24, 2020 at 3:44 AM Roger Pau Monné wrote:
> >
> > On Thu, Apr 23, 2020 at 08:30:06AM -0700, Tamas K Lengyel wrote:
> > > When resetting a VM fork we ought to only remove pages that were
> > > allocated for
> > > the
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a
On Fri, Apr 24, 2020 at 3:44 AM Roger Pau Monné wrote:
>
> On Thu, Apr 23, 2020 at 08:30:06AM -0700, Tamas K Lengyel wrote:
> > When resetting a VM fork we ought to only remove pages that were allocated
> > for
> > the fork during it's execution and the contents copied over from the parent.
> >
> On Apr 24, 2020, at 5:04 AM, Nick Rosbrook wrote:
>
> On Thu, Apr 23, 2020 at 1:22 PM George Dunlap
> wrote:
>>
>>
>>> On Apr 23, 2020, at 12:49 PM, George Dunlap
>>> wrote:
>>>
>>>
>>>
On Apr 23, 2020, at 12:27 PM, Ian Jackson wrote:
Ian Jackson writes ("Re: Golang
On 24.04.2020 11:45, Anthony PERARD wrote:
> On Thu, Apr 23, 2020 at 06:40:33PM +0200, Jan Beulich wrote:
>> On 21.04.2020 18:11, Anthony PERARD wrote:
>>> --- a/xen/arch/x86/Rules.mk
>>> +++ b/xen/arch/x86/Rules.mk
> [..]
>>> +c_flags += $(object_label_flags) $(CFLAGS-stack-boundary)
>>> +a_flags
On 24.04.2020 11:02, Julien Grall wrote:
> On 17/04/2020 10:52, Hongyan Xia wrote:
>> @@ -763,10 +763,10 @@ static void cleanup_frame_table(struct mem_hotadd_info
>> *info)
>> continue;
>> }
>> - ASSERT(l1e_get_flags(l2e_to_l1e(l2e)[l1_table_offset(sva)]) &
>> -
> -Original Message-
> From: Julien Grall
> Sent: 24 April 2020 11:35
> To: p...@xen.org; 'Jan Beulich' ;
> xen-devel@lists.xenproject.org
> Cc: 'Andrew Cooper' ; 'George Dunlap'
> ; 'Ian
> Jackson' ; 'Stefano Stabellini'
> ; 'Wei Liu'
>
> Subject: Re: [PATCH 0/3] xenoprof: XSA-313
Hi Paul,
On 20/04/2020 16:01, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 20 April 2020 15:15
To: p...@xen.org; 'Jan Beulich' ;
xen-devel@lists.xenproject.org
Cc: 'Andrew Cooper' ; 'George Dunlap'
; 'Ian
Jackson' ; 'Stefano Stabellini'
; 'Wei Liu'
Subject: Re:
On 24/04/2020 11:24, Jan Beulich wrote:
> It's definition is bogus when it comes to Hygon CPUs, but since we don't
> use it anywhere drop it rather than correcting it.
>
> Signed-off-by: Jan Beulich
I had wondered about that too.
Acked-by: Andrew Cooper
It's definition is bogus when it comes to Hygon CPUs, but since we don't
use it anywhere drop it rather than correcting it.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -66,8 +66,6 @@
/* CPUID level 0x8001.edx */
#define
flight 149773 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149773/
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
On Thu, Apr 23, 2020 at 06:40:33PM +0200, Jan Beulich wrote:
> On 21.04.2020 18:11, Anthony PERARD wrote:
> > Instead of generating the CFLAGS in Rules.mk everytime we enter a new
> > subdirectory, we are going to generate most of them a single time, and
> > export the result in the environment so
On Thu, Apr 23, 2020 at 08:30:06AM -0700, Tamas K Lengyel wrote:
> When resetting a VM fork we ought to only remove pages that were allocated for
> the fork during it's execution and the contents copied over from the parent.
> This can be determined if the page is sharable as special pages used by
On 21/04/2020 17:12, Anthony PERARD wrote:
In Arm and X86 makefile, generating the linker script is the same, so
we can simply have both call the same macro.
We need to add *.lds files into extra-y so that Rules.mk can find the
.*.cmd dependency file and load it.
Change made to the command
Hi,
On 21/04/2020 17:11, Anthony PERARD wrote:
This patch start to use if_changed introduced in a previous commit.
Whenever if_changed is called, the target must have FORCE as
dependency so that if_changed can check if the command line to be
run has changed, so the macro $(real-prereqs) must
Hi Anthony,
On 21/04/2020 17:11, Anthony PERARD wrote:
Instead of generating the CFLAGS in Rules.mk everytime we enter a new
subdirectory, we are going to generate most of them a single time, and
export the result in the environment so that Rules.mk can use it. The
only flags left to be
On 24/04/2020 10:21, Hongyan Xia wrote:
Hi Julien,
On Fri, 2020-04-24 at 09:59 +0100, Julien Grall wrote:
(resending)
On 17/04/2020 10:52, Hongyan Xia wrote:
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
Hi Julien,
On Fri, 2020-04-24 at 09:59 +0100, Julien Grall wrote:
> (resending)
>
> On 17/04/2020 10:52, Hongyan Xia wrote:
> > 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
Hi,
On 21/04/2020 17:11, Anthony PERARD wrote:
In a later patch ("xen/build: have the root Makefile generates the
CFLAGS), we want to generate the CFLAGS in xen/Makefile, then export
it and have Rules.mk use a CFLAGS from the environment variables. That
changes the flavor of the CFLAGS and
Hi,
On 17/04/2020 10:52, Hongyan Xia wrote:
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi,
On 17/04/2020 10:52, Hongyan Xia wrote:
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi,
On 17/04/2020 10:52, Hongyan Xia wrote:
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Julien Grall
---
xen/arch/x86/smpboot.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/smpboot.c
Hi Hongyan,
On 17/04/2020 10:52, Hongyan Xia wrote:
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
Hi,
On 17/04/2020 10:52, Hongyan Xia wrote:
From: Wei Liu
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
On 17/04/2020 10:52, Hongyan Xia wrote:
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
(resending)
On 17/04/2020 10:52, Hongyan Xia wrote:
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
On 24/04/2020 09:58, Julien Grall wrote:
Hi,
On 17/04/2020 10:52, Hongyan Xia wrote:> diff --git
a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c> index
e85ef449f3..18210405f4 100644> --- a/xen/arch/x86/x86_64/mm.c> +++
b/xen/arch/x86/x86_64/mm.c> @@ -737,8 +737,8 @@ static void
Hi,
On 17/04/2020 10:52, Hongyan Xia wrote:> diff --git
a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c> index
e85ef449f3..18210405f4 100644> --- a/xen/arch/x86/x86_64/mm.c> +++
b/xen/arch/x86/x86_64/mm.c> @@ -737,8 +737,8 @@ static void
cleanup_frame_table(struct mem_hotadd_info
A gentle ping.
On Fri, 2020-04-17 at 10:52 +0100, Hongyan Xia wrote:
> 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.
>
>
> -Original Message-
> On 24.04.2020 09:38, Paul Durrant wrote:
> > * Memory read caching in emulation (v5)
> > - Jan Beulich
>
> Unless issues are found with this, it can be moved to "completed" -
> I did commit this yesterday.
>
Someone just drew my attention to the commit so once
On 24.04.2020 09:38, Paul Durrant wrote:
> * Memory read caching in emulation (v5)
> - Jan Beulich
Unless issues are found with this, it can be moved to "completed" -
I did commit this yesterday.
Jan
*** ONE WEEK 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
On 23.04.2020 23:53, osstest service owner wrote:
> flight 149752 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/149752/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386-prev 6
On 23.04.2020 20:49, Andrew Cooper wrote:
> On 21/04/2020 08:48, Jan Beulich wrote:
>> On 20.04.2020 16:59, Andrew Cooper wrote:
>>> --- a/xen/include/asm-x86/processor.h
>>> +++ b/xen/include/asm-x86/processor.h
>>> @@ -441,12 +441,18 @@ struct tss_page {
>>> };
>>> DECLARE_PER_CPU(struct
On 23.04.2020 20:24, Andrew Cooper wrote:
> On 21/04/2020 08:24, Jan Beulich wrote:
>> On 20.04.2020 16:59, Andrew Cooper wrote:
>>> @@ -46,24 +36,13 @@ void restore_rest_processor_state(void)
>>> /* Restore full CR4 (inc MCE) now that the IDT is in place. */
>>>
On 23.04.2020 19:35, Andrew Cooper wrote:
> On 21/04/2020 07:02, Jan Beulich wrote:
>> On 20.04.2020 20:05, Andrew Cooper wrote:
>>> On 20/04/2020 15:05, Jan Beulich wrote:
I'm in particular
concerned that we may gain a large number of such printk()s over
time, if we added them in
88 matches
Mail list logo
