flight 167509 qemu-mainline real [real]
flight 167514 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167509/
http://logs.test-lab.xenproject.org/osstest/logs/167514/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 167508 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167508/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 167500
test-amd64-amd64-qemuu-nested-amd 20
flight 167504 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167504/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 14 guest-start fail REGR. vs. 167497
Tests which did not
On Tue, 21 Dec 2021, Anthony PERARD wrote:
> On Fri, Dec 17, 2021 at 12:15:25PM +, Oleksii Moisieiev wrote:
> > > On 14.12.21 11:34, Oleksii Moisieiev wrote:
> > > > @@ -1817,17 +1858,24 @@ static void libxl__add_dtdevs(libxl__egc *egc,
> > > > libxl__ao *ao, uint32_t domid,
> > > > {
> > >
On Tue, 21 Dec 2021, Oleksii Moisieiev wrote:
> Hi Stefano,
>
> On Mon, Dec 20, 2021 at 04:52:01PM -0800, Stefano Stabellini wrote:
> > On Mon, 20 Dec 2021, Oleksii Moisieiev wrote:
> > > Hi Stefano,
> > >
> > > On Fri, Dec 17, 2021 at 06:14:55PM -0800, Stefano Stabellini wrote:
> > > > On Tue,
Hi Stefano,
On Mon, Dec 20, 2021 at 04:52:01PM -0800, Stefano Stabellini wrote:
> On Mon, 20 Dec 2021, Oleksii Moisieiev wrote:
> > Hi Stefano,
> >
> > On Fri, Dec 17, 2021 at 06:14:55PM -0800, Stefano Stabellini wrote:
> > > On Tue, 14 Dec 2021, Oleksii Moisieiev wrote:
> > > > This is the
On Wed, Dec 22, 2021 at 02:19:03AM +0800, G.R. wrote:
> > > I omitted all operational details with the assumption that you are
> > > familiar
> > > with TrueNAS and iSCSI setup.
> >
> > Not really. Ideally I would like a way to reproduce that can be done
> > using iperf, nc or similar simple
flight 167501 qemu-mainline real [real]
flight 167507 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/167501/
http://logs.test-lab.xenproject.org/osstest/logs/167507/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
> > I omitted all operational details with the assumption that you are familiar
> > with TrueNAS and iSCSI setup.
>
> Not really. Ideally I would like a way to reproduce that can be done
> using iperf, nc or similar simple command line tool, without requiring
> to setup iSCSI.
I think it would be
On Thu, Dec 16, 2021 at 06:47:17PM +, Andrew Cooper wrote:
> On 06/12/2021 17:02, Anthony PERARD wrote:
> > Fix the dependency on the library, $(SHLIB) variable doesn't exist
> > anymore.
> >
> > Rework dependency on the include file, we can let `swig` generate the
> > dependency for us with
On Tue, Dec 07, 2021 at 02:20:29PM +0100, Juergen Gross wrote:
> On 06.12.21 18:02, Anthony PERARD wrote:
> > There is no need for an extra "installlocal" target, we can use
> > double-colon rules instead.
>
> Doesn't that mean that with the ultimate goal of including all
> Makefiles of the tree
flight 167500 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167500/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 167495
Tests which did not
On Thu, Dec 16, 2021 at 06:03:54PM +, Andrew Cooper wrote:
> On 06/12/2021 17:02, Anthony PERARD wrote:
> > Setup proper dependencies with libacpi so we don't need to run "make
> > hvmloader" in the "all" target. ("build.o" new prerequisite isn't
> > exactly proper but a side effect of
On Thu, Dec 16, 2021 at 05:57:43PM +, Andrew Cooper wrote:
> On 06/12/2021 17:02, Anthony PERARD wrote:
> > diff --git a/tools/examples/Makefile b/tools/examples/Makefile
> > index 14e24f4cb3..48b520e133 100644
> > --- a/tools/examples/Makefile
> > +++ b/tools/examples/Makefile
> > @@ -26,10
On Thu, Dec 16, 2021 at 05:55:29PM +, Andrew Cooper wrote:
> On 06/12/2021 17:02, Anthony PERARD wrote:
> > diff --git a/tools/debugger/gdbsx/Makefile b/tools/debugger/gdbsx/Makefile
> > index 8d7cd94a31..4aaf427c45 100644
> > --- a/tools/debugger/gdbsx/Makefile
> > +++
On Thu, Dec 16, 2021 at 05:26:49PM +, Andrew Cooper wrote:
> On 06/12/2021 17:02, Anthony PERARD wrote:
> > Sources of both xenconsoled and xenconsole are already separated into
> > different directory and don't share anything in common. Having two
> > different Makefile means it's easier to
On Thu, Dec 16, 2021 at 05:16:05PM +, Andrew Cooper wrote:
> On 06/12/2021 17:02, Anthony PERARD wrote:
> > diff --git a/tools/libs/guest/Makefile b/tools/libs/guest/Makefile
> > index 8f5f3acd21..1f4b7f7c58 100644
> > --- a/tools/libs/guest/Makefile
> > +++ b/tools/libs/guest/Makefile
> > @@
On Thu, Dec 16, 2021 at 12:36:41PM +, Andrew Cooper wrote:
> On 06/12/2021 17:01, Anthony PERARD wrote:
> > @@ -35,21 +29,13 @@ flask-set-bool: set-bool.o
> >
> > .PHONY: clean
> > clean:
> > - rm -f *.o *.opic *.so
> > + rm -f *.o
> > rm -f $(CLIENTS)
> > $(RM) $(DEPS_RM)
>
On Fri, Dec 17, 2021 at 06:50:02PM +0200, Oleksandr wrote:
> On 17.12.21 17:26, Juergen Gross wrote:
> > On 15.12.21 22:36, Oleksandr wrote:
> > > On 15.12.21 17:58, Juergen Gross wrote:
> > > > In practice we are having something like the "protocol" already today:
> > > > the disk device name is
On 25.11.2021 14:39, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> br.build-system-xen-v8
>
> v8:
> Mostly rework of v7. With many patch already applied.
> Some detail changes that are spread
On Tue, Dec 21, 2021 at 03:23:48PM +0100, Jan Beulich wrote:
> On 25.11.2021 14:39, Anthony PERARD wrote:
> > From: Anthony PERARD
> >
> > zconf_fopen() will open file in $srctree if the file isn't in
> > $objtree. This is an issue for "auto.conf" as it could be in the
> > source tree if it is
On Fri, Dec 17, 2021 at 12:15:25PM +, Oleksii Moisieiev wrote:
> > On 14.12.21 11:34, Oleksii Moisieiev wrote:
> > > @@ -1817,17 +1858,24 @@ static void libxl__add_dtdevs(libxl__egc *egc,
> > > libxl__ao *ao, uint32_t domid,
> > > {
> > > AO_GC;
> > > libxl__ao_device *aodev =
On 25.11.2021 14:39, Anthony PERARD wrote:
> From: Anthony PERARD
>
> zconf_fopen() will open file in $srctree if the file isn't in
> $objtree. This is an issue for "auto.conf" as it could be in the
> source tree if it is dirty. With "auto.conf" read from the source
> tree, kconfig will not
On 25.11.2021 14:39, Anthony PERARD wrote:
> I guess it's easier to remember that %.E does "$(CC) -E" or "$(CPP)".
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Anthony PERARD
I understand that this patch isn't going to be needed anymore.
Jan
On 25.11.2021 14:39, Anthony PERARD wrote:
> Reorganize a bit the Makefile ahead of patch
> "build: adding out-of-tree support to the xen build"
Without you saying so it's not clear why that's good of even
necessary. Moving things around always has the potential of
breaking subtle ordering
On 25.11.2021 14:39, Anthony PERARD wrote:
> When doing an out-of-tree build, and thus setting VPATH,
> GNU Make 3.81 on Ubuntu Trusty complains about Circular dependency of
> include/Makefile and include/xlat.lst and drop them. The build fails
> later due to headers malformed.
A circular
On 25.11.2021 14:39, Anthony PERARD wrote:
> @@ -81,10 +81,21 @@ ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
>
> all: $(obj)/headers.chk $(obj)/headers99.chk $(obj)/headers++.chk
>
> -PUBLIC_HEADERS := $(filter-out $(src)/public/arch-%
> $(src)/public/dom0_ops.h, $(wildcard
On 25.11.2021 14:39, Anthony PERARD wrote:
> $(srctree) is a better description for the source directory than
> $(BASEDIR) that has been used for both source and build directory
> (which where the same).
>
> This adds $(srctree) to a few path where make's VPATH=$(srctree) won't
> apply. And
On 25.11.2021 14:39, Anthony PERARD wrote:
> We need to differentiate between source files and generated/built
> files. We will be replacing $(BASEDIR) by $(objtree) for files that
> are generated.
>
> Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
On 25.11.2021 14:39, Anthony PERARD wrote:
> Rather than preparing the efi source file, we will make the symbolic
> link as needed from the build location.
>
> The `ln` command is run every time to allow to update the link in case
> the source tree change location.
Btw, since symlinks aren't
On Tue, Dec 21, 2021 at 01:13:43AM +0800, G.R. wrote:
> First of all, thank you for your quick response, Juergen and Roger.
> I just realized that I run into mail forwarding issue from sourceforge
> mail alias service, and only found the responses when I checked the
> list archive. As a result, I
On Tue, Dec 21, 2021 at 10:06:37AM +0100, Jan Beulich wrote:
> Since mail to Lukasz'es address has been bouncing, Intel have suggested
> replacement contacts.
>
> Signed-off-by: Jan Beulich
> ---
> To be frank, I'm not fully convinced of the M: - I'd instead see us use
> R: for both just like we
On 25.11.2021 14:39, Anthony PERARD wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -171,6 +171,10 @@ export LEX = $(if $(FLEX),$(FLEX),flex)
> # Default file for 'make defconfig'.
> export KBUILD_DEFCONFIG := $(ARCH)_defconfig
>
> +# Copy CFLAGS generated by "Config.mk" so they can be
On Tue, Dec 14, 2021 at 09:34:28AM +, Oleksii Moisieiev wrote:
> This enumeration sets SCI type for the domain. Currently there is
> two possible options: either 'none' or 'scmi_smc'.
>
> 'none' is the default value and it disables SCI support at all.
>
> 'scmi_smc' enables access to the
flight 167503 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167503/
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 16.12.2021 10:54, Andrew Cooper wrote:
> With all infrastructure in place, advertise the PKS CPUID bit to guests, and
> let them set CR4.PKS.
>
> Experiment with a tweak to the layout of hvm_cr4_guest_valid_bits() so future
> additions will be just a single added line.
>
> The current context
On 16.12.2021 10:54, Andrew Cooper wrote:
> PKS is incredibly similar to the existing PKU behaviour, operating on
> pagewalks for any supervisor mapping.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
From: Christopher Clark
This is a split out of the hyperlaunch dom0 series.
There were several instances of open-coded domid range checking. This commit
replaces those with the is_system_domain or is_system_domid inline function.
Signed-off-by: Christopher Clark
Signed-off-by: Daniel P. Smith
On 12/21/21 4:20 AM, Jan Beulich wrote:
On 20.12.2021 17:28, Daniel P. Smith wrote:
From: Christopher Clark
This is a split out of the hyperlaunch dom0 series.
There were several instances of open-coded domid range checking. This commit
replaces those with the is_system_domain or
On 16.12.2021 10:54, Andrew Cooper wrote:
> Have guest_{rd,wr}msr() access either the live register, or stashed state,
> depending on context. Include MSR_PKRS for migration, and let the guest have
> full access.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 16.12.2021 10:54, Andrew Cooper wrote:
> Under PKS, MSR_PKRS is available and based on the CPUID policy alone, and
> usable independently of CR4.PKS. See the large comment in prot-key.h for
> details of the context switching arrangement.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan
On 16.12.2021 10:54, Andrew Cooper wrote:
> asm/processor.h is in desperate need of splitting up, and protection key
> functionality in only used in the emulator and pagewalk. Introduce a new
> asm/prot-key.h and move the relevant content over.
>
> Rename the PKRU_* constants to drop the user
flight 167497 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167497/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in
167485 pass in 167497
On 16.12.2021 10:54, Andrew Cooper wrote:
> Protection Key Supervisor works in a very similar way to Protection Key User,
> except that instead of a PKRU register used by the {RD,WR}PKRU instructions,
> the supervisor protection settings live in MSR_PKRS and is accessed using
> normal {RD,WR}MSR
On Tue, Dec 21, 2021 at 10:59:27AM +0100, Jan Beulich wrote:
> There's no point producing a long chain of zeroes when the previously
> calculated total value was zero. To guard against mistakenly skipping
> non-zero individual fields, widen "sum" to "unsigned long long".
>
> Signed-off-by: Jan
On 17.12.2021 16:00, Andrew Cooper wrote:
> On 03/12/2021 12:05, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
>> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
>> @@ -220,6 +220,8 @@ static inline void pi_clear_sn(struct pi
>> #define EXIT_REASON_XSAVES 63
>> #define
flight 167499 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/167499/
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
There's no point producing a long chain of zeroes when the previously
calculated total value was zero. To guard against mistakenly skipping
non-zero individual fields, widen "sum" to "unsigned long long".
Signed-off-by: Jan Beulich
--- a/tools/misc/xenperf.c
+++ b/tools/misc/xenperf.c
@@ -76,7
Hi Jan
> On 21 Dec 2021, at 7:41 am, Jan Beulich wrote:
>
> On 17.12.2021 15:32, Julien Grall wrote:
>> On 16/12/2021 13:37, Jan Beulich wrote:
>>> On 16.12.2021 12:01, Roger Pau Monné wrote:
On Thu, Dec 16, 2021 at 10:18:32AM +, Rahul Singh wrote:
>> On 14 Dec 2021, at 12:37 pm,
On Tue, Dec 21, 2021 at 08:55:26AM +0100, Jan Beulich wrote:
> On 20.12.2021 12:29, Anthony PERARD wrote:
> > On Thu, Dec 16, 2021 at 11:08:47AM +, Anthony PERARD wrote:
> >> On Tue, Dec 07, 2021 at 12:10:34PM +0100, Jan Beulich wrote:
> >>> On 25.11.2021 14:39, Anthony PERARD wrote:
>
Hi Jan,
> On 24 Sep 2021, at 10:43 am, Jan Beulich wrote:
>
> Generic code will use this information to determine what order values
> can legitimately be passed to the ->{,un}map_page() hooks. For now all
> ops structures simply get to announce 4k mappings (as base page size),
> and there is
On 20.12.2021 17:28, Daniel P. Smith wrote:
> From: Christopher Clark
>
> This is a split out of the hyperlaunch dom0 series.
>
> There were several instances of open-coded domid range checking. This commit
> replaces those with the is_system_domain or is_system_domid inline function.
>
>
Hi Juergen,
On 21/12/2021 08:45, Juergen Gross wrote:
On 20.12.21 18:14, Julien Grall wrote:
Hi,
On 18/12/2021 00:00, Stefano Stabellini wrote:
On Fri, 17 Dec 2021, Juergen Gross wrote:
On 17.12.21 11:41, Julien Grall wrote:
Hi Juergen,
On 17/12/2021 08:50, Juergen Gross wrote:
On
Since mail to Lukasz'es address has been bouncing, Intel have suggested
replacement contacts.
Signed-off-by: Jan Beulich
---
To be frank, I'm not fully convinced of the M: - I'd instead see us use
R: for both just like we had it for Lukasz.
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -316,7 +316,8
Having grant table code in arch/x86/mm.c seems wrong. Move it to the
new file arch/x86/gnttab.c, especially as the amount of code is
expected to grow further.
While doing that replace type casts to pte_t with the more appropriate
__pte() macro.
No functional change.
Signed-off-by: Juergen
Add two functions for adding reserved areas to the memory map and
for removing them again.
Those will be needed for proper grant table/mapping support in PVH
mode.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
V2:
- fix e820_put_reserved_pfns() (Samuel Thibault)
---
e820.c
Today Mini-OS won't look at the memory map when ballooning up. This can
result in problems for PVH domains with more than 4 GB of RAM, as
ballooning will happily run into the ACPI area.
Fix that by adding only pages being marked as RAM in the memory map and
by distinguishing between the current
For being able to use the grant mapping interface in PVH mode some
changes are required, as the guest needs to specify a physical address
in the hypercall interface.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
gntmap.c | 81
arch/x86/setup.c is repeating the definition of __pte() instead using
the appropriate header. Fix that.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
arch/x86/setup.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
Introduce e820.c containing all the E820 memory map handling.
No functional change.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
Makefile | 1 +
arch/arm/mm.c | 8
arch/x86/mm.c | 70 +
e820.c | 119
Instead of passing the pointer of a grantmap entry to the
_gntmap_[un]map_grant_ref() sub-functions use the map pointer and the
entry index instead. This will be needed for PVH mode usage.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
gntmap.c | 48
Do some processing of the E820 memory map obtained from the hypervisor:
- align the entries to page boundaries
- sort the entries by their start address
- merge adjacent entries of same type
This is relevant for PVH mode only.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
V2:
Mini-OS in PVH mode is missing some features, especially in the areas
of ballooning and grant tables.
With this series I am able to run Xenstore stubdom in PVH mode.
Changes in V3:
- two minor fixes
Changes in V2:
- multiple comments addressed
Juergen Gross (10):
mini-os: split e820 map
Sizing the available memory should respect memory holes, so look at
the memory map when setting the boundary for the memory allocator.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
V2:
- rename "max" to "start" (Samuel Thibault)
---
arch/x86/mm.c | 6 +-
e820.c |
Grant table initialization for PVH requires some additional actions
compared to PV mode. Add those.
Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
---
arch/x86/gnttab.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/x86/gnttab.c
Juergen Gross, le mar. 21 déc. 2021 07:16:49 +0100, a ecrit:
> On 21.12.21 00:22, Samuel Thibault wrote:
> > Juergen Gross, le lun. 20 déc. 2021 17:07:10 +0100, a ecrit:
> > > +unsigned long e820_get_max_contig_pages(unsigned long pfn, unsigned long
> > > pages)
> > > +{
> > > +int i;
> > > +
On 20.12.2021 16:25, Roger Pau Monné wrote:
> I think it might be interesting to add some kind of unit testing to
> this code in tools/tests. It's a standalone piece of code that could
> be easily tested for correct functionality. Not that you should do it
> here, in fact it might be interesting
On 16.12.2021 12:30, Rahul Singh wrote:
>> On 24 Sep 2021, at 10:53 am, Jan Beulich wrote:
>>
>> Having a separate flush-all hook has always been puzzling me some. We
>> will want to be able to force a full flush via accumulated flush flags
>> from the map/unmap functions. Introduce a respective
68 matches
Mail list logo
