Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Tuesday, May 18, 2021 6:21 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH 06/10] xen: replace order with nr_pfns in assign_pages
>
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Tuesday, May 18, 2021 6:15 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH 05/10] xen/arm: introduce alloc_staticmem_pages
>
> Hi
flight 162075 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162075/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 162023
build-armhf
On 17.5.2021 17.24, Connor Davis wrote:
>
> On 5/17/21 8:13 AM, Jan Beulich wrote:
>> On 17.05.2021 15:48, Connor Davis wrote:
>>> On 5/17/21 3:32 AM, Jan Beulich wrote:
On 14.05.2021 02:56, Connor Davis wrote:
> Check if the debug capability is enabled in early_xdbc_parse_parameter,
flight 162058 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162058/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161990
test-armhf-armhf-libvirt 16
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Tuesday, May 18, 2021 6:01 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH 04/10] xen/arm: static memory initialization
>
> Hi
flight 162072 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162072/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 162023
build-armhf
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Tuesday, May 18, 2021 5:46 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH 03/10] xen/arm: introduce PGC_reserved
>
>
>
> On
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Tuesday, May 18, 2021 4:58 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
> ; nd
> Subject: Re: [PATCH 01/10] xen/arm: introduce domain on Static Allocation
>
flight 162019 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162019/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
flight 162067 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 162023
build-armhf
flight 162065 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162065/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 162023
build-armhf
flight 162062 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 162023
build-armhf
flight 161996 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161996/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug
flight 162046 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162046/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 42ec0a315b8a2f445b7a7d74b8d78965f1dff8f6
baseline version:
ovmf
flight 162055 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162055/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 162023
build-armhf
Hi Juergen,
I have started to look at preserving transaction accross Live-update in
C Xenstored. So far, I managed to transfer transaction that read/write
existing nodes.
Now, I am running into trouble to transfer new/deleted node within a
transaction with the existing migration format.
C
flight 161990 xen-unstable real [real]
flight 162045 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161990/
http://logs.test-lab.xenproject.org/osstest/logs/162045/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Phillip Susi writes:
> Dmitry Torokhov writes:
>
>> By doing this you are stopping delivery of all key events from this
>> device.
Hrm... I don't have very many "interesting" keys to test, but when I hit
the menu key, I see KEY_COMPOSE, which is > KEY_MIN_INTERESTING. When I
press the button
On Mon, May 17, 2021 at 03:24:28PM +0200, Jan Beulich wrote:
> On 17.05.2021 15:20, Daniel Kiper wrote:
> > On Mon, May 17, 2021 at 08:48:32AM +0200, Jan Beulich wrote:
> >> On 07.05.2021 22:26, Bob Eshleman wrote:
> >>> What is your intuition WRT the idea that instead of trying add a PE/COFF
>
flight 162036 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162036/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 162023
build-armhf
On 18/05/2021 18:03, Julien Grall wrote:
> From: Julien Grall
>
> Gitlab CI spotted an issue when building the tools Arm:
>
> xg_dom_arm.c: In function 'meminit':
> xg_dom_arm.c:401:50: error: passing argument 3 of 'set_mode' discards 'const'
> qualifier from pointer target type
From: Julien Grall
Gitlab CI spotted an issue when building the tools Arm:
xg_dom_arm.c: In function 'meminit':
xg_dom_arm.c:401:50: error: passing argument 3 of 'set_mode' discards 'const'
qualifier from pointer target type [-Werror=discarded-qualifiers]
401 | rc = set_mode(dom->xch,
flight 162002 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162002/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 29e300ff815283259e81822ed3cb926bb9ad6460
baseline version:
ovmf
Fix the build inside our openSUSE Tumbleweed container by using
adding libzstd headers. While there, remove the explicit dependency
for python and python3 as the respective -devel packages will pull
them in anyway.
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
Cc: Roger Pau Monne
Cc:
Use DOCKER_CMD from the environment (if defined) in the containers'
makefile too, so that, e.g., when doing `export DOCKED_CMD=podman`
podman is used for building the containers too.
Signed-off-by: Dario Faggioli
Acked-by: Roger Pau Monné
---
Cc: Doug Goldstein
Cc: Andrew Cooper
---
Changes
Fix the build in the openSUSE Tumbleweed container within our CI. There
was a missing dependency (libzstd-devel), which needs to be added to the
dockerfile.
OTOH, python3-devel was in the dockerfile already, and hence it should
be there in the image. Yet, build was failing due to that... Maybe we
Dmitry Torokhov writes:
> By doing this you are stopping delivery of all key events from this
> device.
It does? How does the PS/2 keyboard driver work then? It has no way of
knowning what keys the keyboard has other than waiting to see what scan
codes are emitted.
If the keys must be
When multiple PCI devices get assigned to a guest right at boot, libxl
incrementally populates the backend tree. The writes for the first of
the devices trigger the backend watch. In turn xen_pcibk_setup_backend()
will set the XenBus state to Initialised, at which point no further
reconfigures
The commit referenced below was incomplete: It merely affected what
would get written to the vdev- xenstore node. The guest would still
find the function at the original function number as long as
__xen_pcibk_get_pci_dev() wouldn't be in sync. The same goes for AER wrt
> On 18 May 2021, at 16:21, Julien Grall wrote:
>
> From: Julien Grall
>
> The parameter of check_domains() is not used within the function. In fact,
> this was a left over of the original implementation as the version merged
> doesn't need to know whether we are restoring.
>
> So remove
The first change completes a several years old but still incomplete
change. As mentioned there, reverting the original change may also
be an option. The second change works around some odd libxl behavior,
as described in [1]. As per a response to that mail addressing the
issue in libxl may also be
On Tue, May 18, 2021 at 03:01:34PM +0100, Julien Grall wrote:
> From: Julien Grall
>
> Literal strings are not meant to be modified. So we should use const
> char * rather than char * when we want to store a pointer to them.
>
> Take the opportunity to remove the cast (char *) in
flight 162023 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162023/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
On 18.05.21 17:21, Julien Grall wrote:
From: Julien Grall
The parameter of check_domains() is not used within the function. In fact,
this was a left over of the original implementation as the version merged
doesn't need to know whether we are restoring.
So remove it.
Signed-off-by: Julien
On Tue, 2021-05-18 at 16:33 +0200, Dario Faggioli wrote:
> On Tue, 2021-05-18 at 15:20 +0200, Roger Pau Monné wrote:
> > On Tue, May 18, 2021 at 02:04:13PM +0200, Dario Faggioli wrote:
> > > From: Dario Faggioli
> > >
> Mmm... this email address does not really exist, and it's a mistake
> that
Hello,
While trying to build Xen on openSUSE Tumbleweed, I run into this
error, when qemu-xen is being built:
ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)
make[1]: *** [Makefile:53: multiboot.img] Error 1
make: *** [Makefile:576: pc-bios/optionrom/all] Error 2
make:
Hi,
Please ignore this patch. I forgot to CC the maintainers. I will resend it.
Sorry for the noise.
Cheers,
On 18/05/2021 16:21, Julien Grall wrote:
From: Julien Grall
The parameter of check_domains() is not used within the function. In fact,
this was a left over of the original
From: Julien Grall
The parameter of check_domains() is not used within the function. In fact,
this was a left over of the original implementation as the version merged
doesn't need to know whether we are restoring.
So remove it.
Signed-off-by: Julien Grall
---
From: Julien Grall
The parameter of check_domains() is not used within the function. In fact,
this was a left over of the original implementation as the version merged
doesn't need to know whether we are restoring.
So remove it.
Signed-off-by: Julien Grall
---
Hi Jan,
On 18/05/2021 16:13, Jan Beulich wrote:
On 18.05.2021 16:06, Julien Grall wrote:
On 18/05/2021 07:27, Jan Beulich wrote:
On 18.05.2021 06:11, Connor Davis wrote:
On 5/17/21 9:42 AM, Julien Grall wrote:
Hi Jan,
On 17/05/2021 12:16, Jan Beulich wrote:
On 14.05.2021 20:53, Connor
On 18.05.2021 16:06, Julien Grall wrote:
>
>
> On 18/05/2021 07:27, Jan Beulich wrote:
>> On 18.05.2021 06:11, Connor Davis wrote:
>>>
>>> On 5/17/21 9:42 AM, Julien Grall wrote:
Hi Jan,
On 17/05/2021 12:16, Jan Beulich wrote:
> On 14.05.2021 20:53, Connor Davis wrote:
>>
On Tue, May 18, 2021 at 04:33:43PM +0200, Dario Faggioli wrote:
> On Tue, 2021-05-18 at 15:20 +0200, Roger Pau Monné wrote:
> > On Tue, May 18, 2021 at 02:04:13PM +0200, Dario Faggioli wrote:
> > > From: Dario Faggioli
> > >
> Mmm... this email address does not really exist, and it's a mistake
>
On 18.05.2021 16:01, Julien Grall wrote:
> From: Julien Grall
>
> Literal strings are not meant to be modified. So we should use const
> char * rather than char * when we want to store a pointer to them.
>
> The array should also not be modified at all and is only used by
> xenlog_update_val().
Pass an hvm boolean parameter to the elf note parsing and checking
routines, so that better checking can be done in case libelf is
dealing with an hvm container.
elf_xen_note_check shouldn't return early unless PHYS32_ENTRY is set
and the container is of type HVM, or else the loader and version
> On 18 May 2021, at 15:01, Julien Grall wrote:
>
> From: Julien Grall
>
> Literal strings are not meant to be modified. So we should use const
> char * rather than char * when we want to store a pointer to them.
>
> The array should also not be modified at all and is only used by
>
On Tue, 2021-05-18 at 16:26 +0200, Roger Pau Monné wrote:
> On Tue, May 18, 2021 at 02:04:07PM +0200, Dario Faggioli wrote:
> > From: Dario Faggioli
> >
> > Use DOCKER_CMD from the environment (if defined) in the containers'
> > makefile too, so that, e.g., when doing `export DOCKED_CMD=podman`
On Tue, 2021-05-18 at 15:20 +0200, Roger Pau Monné wrote:
> On Tue, May 18, 2021 at 02:04:13PM +0200, Dario Faggioli wrote:
> > From: Dario Faggioli
> >
Mmm... this email address does not really exist, and it's a mistake
that it ended up here. :-/
> > Fix the build inside our openSUSE
On Tue, May 18, 2021 at 02:04:07PM +0200, Dario Faggioli wrote:
> From: Dario Faggioli
>
> Use DOCKER_CMD from the environment (if defined) in the containers'
> makefile too, so that, e.g., when doing `export DOCKED_CMD=podman`
> podman is used for building the containers too.
>
>
Hi Henry,
On 17/05/2021 07:38, Henry Wang wrote:
From: Julien Grall
On a previous e-mail, you said you tweaked the FVP model to set those
regions. Were you trying to mimick the memory layout of a real HW
(either current or future)?
Not really, I was just trying to cover as many cases as
On 18/05/2021 07:27, Jan Beulich wrote:
On 18.05.2021 06:11, Connor Davis wrote:
On 5/17/21 9:42 AM, Julien Grall wrote:
Hi Jan,
On 17/05/2021 12:16, Jan Beulich wrote:
On 14.05.2021 20:53, Connor Davis wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -294,7 +294,9 @@ int
Hi Wei,
On 17/05/2021 19:41, Wei Liu wrote:
On Mon, May 10, 2021 at 06:49:01PM +0100, Julien Grall wrote:
Hi,
Ian, Wei, Anthony, can I get some feedbacks on the tools side?
I think this is moving to the right direction so
Acked-by: Wei Liu
Thanks! I had committed most of the tools code
From: Julien Grall
Hi all,
By default, both Clang and GCC will happily compile C code where
non-const char * point to literal strings. This means the following
code will be accepted:
char *str = "test";
str[0] = 'a';
Literal strings will reside in rodata, so they are not modifiable.
From: Julien Grall
Literal strings are not meant to be modified. So we should use const
char * rather than char * when we want to store a pointer to them.
The array should also not be modified at all and is only used by
xenlog_update_val(). So take the opportunity to add an extra const and
move
From: Julien Grall
Literal strings are not meant to be modified. So we should use const
char * rather than char * when we want to store a pointer to them.
Take the opportunity to remove the cast (char *) in console_init(). It
is unnecessary and will remove the const.
Signed-off-by: Julien
Hi Anthony,
On 11/05/2021 16:18, Anthony PERARD wrote:
On Mon, Apr 05, 2021 at 04:57:08PM +0100, Julien Grall wrote:
From: Julien Grall
literal strings are not meant to be modified. So we should use const
char * rather than char * when we want to store a pointer to them.
Signed-off-by:
Hi Anthony,
On 11/05/2021 15:58, Anthony PERARD wrote:
On Mon, Apr 05, 2021 at 04:57:04PM +0100, Julien Grall wrote:
From: Julien Grall
literal strings are not meant to be modified. So we should use const
*char rather than char * when we want to store a pointer to them.
Signed-off-by:
On Tue, May 18, 2021 at 02:04:13PM +0200, Dario Faggioli wrote:
> From: Dario Faggioli
>
> Fix the build inside our openSUSE Tumbleweed container by using
> the proper python development packages (and adding zstd headers).
>
> Signed-off-by: Dario Faggioli
> ---
> Cc: Doug Goldstein
> Cc:
Hi Juergen,
On 18/05/2021 07:43, Juergen Gross wrote:
On 17.05.21 17:55, Julien Grall wrote:
So the admin should be able to configure them. At this point, I think
the two limit should be set my the initscript rather than xenstored
itself.
But the admin would need to know the Xen
Hi Juergen,
On 18/05/2021 07:19, Juergen Gross wrote:
The main loop of xenstored is rather complicated due to different
handling of socket and ring-page interfaces. Unify that handling by
introducing interface type specific functions can_read() and
can_write().
Take the opportunity to remove
Hi Penny,
On 18/05/2021 09:57, Penny Zheng wrote:
-Original Message-
From: Jan Beulich
Sent: Tuesday, May 18, 2021 3:35 PM
To: Penny Zheng
Cc: Bertrand Marquis ; Wei Chen
; nd ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org; jul...@xen.org
Subject: Re: [PATCH 07/10] xen/arm:
flight 161986 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161986/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
Hi Penny,
On 18/05/2021 06:21, Penny Zheng wrote:
This commit parses `xen,static-mem` device tree property, to acquire
static memory info reserved for this domain, when constructing domain
during boot-up.
Related info shall be stored in new static_mem value under per domain
struct arch_domain.
Hi Penny,
On 18/05/2021 06:21, Penny Zheng wrote:
This commit introduces allocate_static_memory to allocate static memory as
guest RAM for domain on Static Allocation.
It uses alloc_domstatic_pages to allocate pre-defined static memory banks
for this domain, and uses guest_physmap_add_page to
From: Dario Faggioli
Fix the build inside our openSUSE Tumbleweed container by using
the proper python development packages (and adding zstd headers).
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
Cc: Roger Pau Monne
Cc: Andrew Cooper
---
From: Dario Faggioli
Use DOCKER_CMD from the environment (if defined) in the containers'
makefile too, so that, e.g., when doing `export DOCKED_CMD=podman`
podman is used for building the containers too.
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
Cc: Roger Pau Monne
Cc: Andrew
Building Xen in openSUSE Tumbleweed in the GitLab CI was broken due to
python and libzstd development dependencies, so let's update the docker
file to fix that.
If this change is accepted, I'm happy to push a new, updated, image to
our registry (ISTR that I used to have the right to do that).
Hi Penny,
On 18/05/2021 06:07, Penny Zheng wrote:
Create one design doc for 1:1 direct-map and static allocation.
It is the first draft and aims to describe why and how we allocate
1:1 direct-map(guest physical == physical) domains, and why and how
we let domains on static allocation.
On 18.05.2021 12:50, Roger Pau Monné wrote:
> On Mon, May 17, 2021 at 05:43:33PM +0200, Jan Beulich wrote:
>> On 07.05.2021 13:04, Roger Pau Monne wrote:
>>> @@ -91,6 +91,21 @@ int x86_msr_copy_from_buffer(struct msr_policy *policy,
>>> const msr_entry_buffer_t msrs,
On Fri, May 14, 2021 at 11:11:14AM -0400, Jason Andryuk wrote:
> On Fri, May 14, 2021 at 9:50 AM Roger Pau Monne wrote:
> >
> > Pass an hvm boolean parameter to the elf note parsing and checking
> > routines, so that better checking can be done in case libelf is
> > dealing with an hvm container.
On 18.05.2021 10:38, Penny Zheng wrote:
> Hi Jan
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, May 18, 2021 3:39 PM
>> To: Penny Zheng
>> Cc: Bertrand Marquis ; Wei Chen
>> ; nd ; xen-devel@lists.xenproject.org;
>> sstabell...@kernel.org; jul...@xen.org
>> Subject: Re:
On 18.05.2021 10:57, Penny Zheng wrote:
>> From: Jan Beulich
>> Sent: Tuesday, May 18, 2021 3:35 PM
>>
>> On 18.05.2021 07:21, Penny Zheng wrote:
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc.c
>>> @@ -2447,6 +2447,9 @@ int assign_pages(
>>> {
>>>
On Mon, May 17, 2021 at 01:09:11PM +0200, Jan Beulich wrote:
> On 14.05.2021 15:50, Roger Pau Monne wrote:
> > @@ -426,7 +426,7 @@ static elf_errorstatus elf_xen_addr_calc_check(struct
> > elf_binary *elf,
> > }
> >
> > /* Initial guess for virt_base is 0 if it is not explicitly
Hi Penny,
On 18/05/2021 06:21, Penny Zheng wrote:
Since page_list under struct domain refers to linked pages as gueast RAM
s/gueast/guest/
allocated from heap, it should not include reserved pages of static memory.
You already have PGC_reserved to indicate they are "static memory". So
On Mon, May 17, 2021 at 05:43:33PM +0200, Jan Beulich wrote:
> On 07.05.2021 13:04, Roger Pau Monne wrote:
> > @@ -91,6 +91,21 @@ int x86_msr_copy_from_buffer(struct msr_policy *policy,
> > const msr_entry_buffer_t msrs, uint32_t
> > nr_entries,
> >
On 18.05.2021 11:51, Penny Zheng wrote:
>> From: Jan Beulich
>> Sent: Tuesday, May 18, 2021 3:16 PM
>>
>> On 18.05.2021 07:21, Penny Zheng wrote:
>>> This patch introduces static memory initialization, during system RAM boot
>> up.
>>>
>>> New func init_staticmem_pages is the equivalent of
On Tue, May 18, 2021 at 09:48:25AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Marek Marczykowski-Górecki
> >
> > On Tue, May 18, 2021 at 09:34:45AM +, Durrant, Paul wrote:
> > > > -Original Message-
> > > > From: Marek Marczykowski-Górecki
> > > >
> > > >
Hi Penny,
Title: s/intruduce/introduce/
On 18/05/2021 06:21, Penny Zheng wrote:
alloc_domstatic_pages is the equivalent of alloc_domheap_pages for
static mmeory, and it is to allocate nr_pfns pages of static memory
and assign them to one specific domain.
It uses alloc_staticmen_pages to get
Hi Penny,
On 18/05/2021 06:21, Penny Zheng wrote:
Function parameter order in assign_pages is always used as 1ul << order,
referring to 2@order pages.
Now, for better compatibility with new static memory, order shall
be replaced with nr_pfns pointing to page count with no constraint,
like
Hi Penny,
On 18/05/2021 06:21, Penny Zheng wrote:
alloc_staticmem_pages is designated to allocate nr_pfns contiguous
pages of static memory. And it is the equivalent of alloc_heap_pages
for static memory.
This commit only covers allocating at specified starting address.
For each page, it shall
Hi Jan,
On 18/05/2021 08:24, Jan Beulich wrote:
On 18.05.2021 07:21, Penny Zheng wrote:
+ * to PGC_state_inuse.
+ */
+pg[i].count_info = (pg[i].count_info & PGC_reserved) | PGC_state_inuse;
+/* Initialise fields which have other uses for free pages. */
+
On 18/05/2021 11:00, Julien Grall wrote:
Hi Penny,
On 18/05/2021 06:21, Penny Zheng wrote:
This patch introduces static memory initialization, during system RAM
boot up.
New func init_staticmem_pages is the equivalent of init_heap_pages,
responsible
for static memory initialization.
Hi Penny,
On 18/05/2021 06:21, Penny Zheng wrote:
This patch introduces static memory initialization, during system RAM boot up.
New func init_staticmem_pages is the equivalent of init_heap_pages, responsible
for static memory initialization.
Helper func free_staticmem_pages is the equivalent
Hi Jan
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, May 18, 2021 3:16 PM
> To: Penny Zheng
> Cc: Bertrand Marquis ; Wei Chen
> ; nd ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 04/10] xen/arm: static memory initialization
On 18/05/2021 06:21, Penny Zheng wrote:
In order to differentiate pages of static memory, from those allocated from
heap, this patch introduces a new page flag PGC_reserved to tell.
New struct reserved in struct page_info is to describe reserved page info,
that is, which specific domain this
Hi Jan
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, May 18, 2021 3:24 PM
> To: Penny Zheng
> Cc: Bertrand Marquis ; Wei Chen
> ; nd ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 05/10] xen/arm: introduce
On Tue, May 18, 2021 at 07:57:16AM +0100, Paul Durrant wrote:
> On 17/05/2021 22:43, Marek Marczykowski-Górecki wrote:
> > On Tue, May 11, 2021 at 12:46:38PM +, Durrant, Paul wrote:
> > > I really can't remember any detail. Perhaps try reverting both patches
> > > then and check that the
Hi Jan
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, May 18, 2021 3:28 PM
> To: Penny Zheng
> Cc: Bertrand Marquis ; Wei Chen
> ; nd ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 06/10] xen: replace order with nr_pfns in
Hi Penny,
On 18/05/2021 06:21, Penny Zheng wrote:
static memory regions overlap with memory nodes. The
overlapping memory is reserved-memory and should be
handled accordingly:
dt_unreserved_regions should skip these regions the
same way they are already skipping mem-reserved regions.
Hi Penny,
On 18/05/2021 06:21, Penny Zheng wrote:
Static Allocation refers to system or sub-system(domains) for which memory
areas are pre-defined by configuration using physical address ranges.
Those pre-defined memory, -- Static Momery, as parts of RAM reserved in the
s/Momery/Memory/
Hi Jan
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, May 18, 2021 3:35 PM
> To: Penny Zheng
> Cc: Bertrand Marquis ; Wei Chen
> ; nd ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 07/10] xen/arm: intruduce
Hi Jan
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, May 18, 2021 3:39 PM
> To: Penny Zheng
> Cc: Bertrand Marquis ; Wei Chen
> ; nd ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 08/10] xen/arm: introduce reserved_page_list
flight 161988 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161988/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 18.05.2021 07:21, Penny Zheng wrote:
> Since page_list under struct domain refers to linked pages as gueast RAM
> allocated from heap, it should not include reserved pages of static memory.
>
> The number of PGC_reserved pages assigned to a domain is tracked in
> a new 'reserved_pages'
On 18.05.2021 07:21, Penny Zheng wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -2447,6 +2447,9 @@ int assign_pages(
> {
> ASSERT(page_get_owner([i]) == NULL);
> page_set_owner([i], d);
> +/* use page_set_reserved_owner to set its
flight 161984 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161984/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
On 18.05.2021 07:21, Penny Zheng wrote:
> Function parameter order in assign_pages is always used as 1ul << order,
> referring to 2@order pages.
>
> Now, for better compatibility with new static memory, order shall
> be replaced with nr_pfns pointing to page count with no constraint,
> like
On 18.05.2021 07:21, Penny Zheng wrote:
> alloc_staticmem_pages is designated to allocate nr_pfns contiguous
> pages of static memory. And it is the equivalent of alloc_heap_pages
> for static memory.
> This commit only covers allocating at specified starting address.
>
> For each page, it shall
On 18.05.2021 07:21, Penny Zheng wrote:
> This patch introduces static memory initialization, during system RAM boot up.
>
> New func init_staticmem_pages is the equivalent of init_heap_pages,
> responsible
> for static memory initialization.
>
> Helper func free_staticmem_pages is the
1 - 100 of 128 matches
Mail list logo
