flight 139371 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139371/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d47b85a621add591212546b12945d7b9873fbabf
baseline version:
ovmf
flight 139366 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139366/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 139177
On 26/07/2019 23:30, Julien Grall wrote:
> Hi Andrew,
>
> Thank you for looking into this.
>
> On 7/26/19 10:08 PM, Andrew Cooper wrote:
>> For cleanup purposes, it is necessary for asm/percpu.h to not use
>> DECLARE_PER_CPU() itself. asm/smp.h is arguably a better place for it to
>> live anyway.
Hi Andrew,
On 7/26/19 10:08 PM, Andrew Cooper wrote:
These macros are identical across the architectures, and shouldn't be separate
from the DEFINE_PER_CPU*() infrastructure.
This converts the final asm/percpu.h includes, which were all using
DECLARE_PER_CPU(), to include xen/percpu.h instead.
Hi Andrew,
On 7/26/19 10:08 PM, Andrew Cooper wrote:
These files either don't use any PER_CPU() infrastructure at all, or use
DEFINE_PER_CPU_*(). This is declared in xen/percpu.h, not asm/percpu.h, which
means that xen/percpu.h is included via a different path.
Signed-off-by: Andrew Cooper
Hi Andrew,
Thank you for looking into this.
On 7/26/19 10:08 PM, Andrew Cooper wrote:
> For cleanup purposes, it is necessary for asm/percpu.h to not use
> DECLARE_PER_CPU() itself. asm/smp.h is arguably a better place for it to
> live anyway.
I have noticed that a lot of arch helpers called by
Building with GCC9 (on openSUSE Tubmleweed) generates a lot of errors of
the "taking address of packed member of ... may result in an unaligned
pointer value" kind.
Updating to upstream commit 1dd56dbd11082 ("[build] Workaround compilation
error with gcc 9.1") seems to fix the problem.
For more
Hi Andrew,
On 7/26/19 9:32 PM, Andrew Cooper wrote:
Future changes are going to need to page align some percpu data.
This means that the percpu area needs suitably aligning in the BSS so CPU0 has
correctly aligned data. Shuffle the exact link order of items within the BSS
to give
This is all cleanup which I got tangled in as part of the TSS xpti v2 fix,
before deciding that this is far too invasive to backport, whereas the TSS fix
itself really does want backporting.
This series is based on:
These files either don't use any PER_CPU() infrastructure at all, or use
DEFINE_PER_CPU_*(). This is declared in xen/percpu.h, not asm/percpu.h, which
means that xen/percpu.h is included via a different path.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
These macros are identical across the architectures, and shouldn't be separate
from the DEFINE_PER_CPU*() infrastructure.
This converts the final asm/percpu.h includes, which were all using
DECLARE_PER_CPU(), to include xen/percpu.h instead.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC:
None of these headers use any PER_CPU() infrastructure.
xen/rwlock.h however does, and picked it up transitively via xen/spinlock.h,
so include it properly.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC:
For cleanup purposes, it is necessary for asm/percpu.h to not use
DECLARE_PER_CPU() itself. asm/smp.h is arguably a better place for it to
live anyway.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
---
xen/include/asm-arm/percpu.h | 6 --
flight 139364 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139364/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 139342
Tests which did
Reworked to allow DEFINE_PER_CPU_PAGE_ALIGNED() to specify the
__aligned(PAGE_SIZE) itself.
Andrew Cooper (2):
xen/link: Introduce .bss.percpu.page_aligned
x86/xpti: Don't leak TSS-adjacent percpu data via Meltdown
xen/arch/arm/xen.lds.S | 5 +++--
xen/arch/x86/setup.c
Future changes are going to need to page align some percpu data.
This means that the percpu area needs suitably aligning in the BSS so CPU0 has
correctly aligned data. Shuffle the exact link order of items within the BSS
to give .bss.percpu.page_aligned appropriate alignment.
In addition, we
The XPTI work restricted the visibility of most of memory, but missed a few
aspects when it came to the TSS.
Given that the TSS is just an object in percpu data, the 4k mapping for it
created in setup_cpu_root_pgt() maps adjacent percpu data, making it all
leakable via Meltdown, even when XPTI is
flight 139380 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139380/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On 2019-07-22 21:11:40 -0400, Andrew Cooper wrote:
> On 23/07/2019 00:50, Johnson, Ethan wrote:
> > (The Xen 4.7 version of the documentation had a little bit
> > more detail at https://xenbits.xen.org/docs/4.7-testing/misc/pvh.html, but
> > it still doesn't have quite what I'm looking for, and
flight 139361 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139361/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580
On 07/26/19 18:06, Anthony PERARD wrote:
> On Wed, Jul 10, 2019 at 04:05:02PM +0200, Laszlo Ersek wrote:
>> On 07/04/19 16:42, Anthony PERARD wrote:
>>> + if (State == NULL) {
>>> +Status = EFI_OUT_OF_RESOURCES;
>>> +goto Error;
>>> + }
>>> +
>>> + Allocation = AllocateReservedPages
Julien Grall writes:
> On 23/07/2019 22:35, Julien Grall wrote:
>> The definition of PRIregister varies between Arm32 and Arm64 (32-bit vs
>> 64-bit). However, some of the users uses the wrong padding.
>>
>> For more consistency, the padding is now moved into the PRIregister and
>> varies
flight 139368 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139368/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 467944ce4546b5d2cd88b15125501d03597920bd
baseline version:
freebsd
Hi,
On 26/07/2019 16:19, Roger Pau Monné wrote:
On Fri, Jul 26, 2019 at 03:45:22PM +0100, Andrew Cooper wrote:
On 26/07/2019 15:38, Roger Pau Monné wrote:
On Fri, Jul 26, 2019 at 02:52:40PM +0100, Andrew Cooper wrote:
There is no way to do this inside DEFINE_PER_CPU_PAGE_ALIGNED(), because
From: Zhang Chen
Xen COLO and KVM COLO shared lots of code in Qemu.
The colo-compare object in Qemu now requires an 'iothread' property since QEMU
2.11.
Detail:
https://wiki.qemu.org/Features/COLO
Signed-off-by: Zhang Chen
Reviewed-by: Anthony PERARD
---
tools/libxl/libxl_dm.c | 4 +++-
1
On Fri, Jul 26, 2019 at 11:43:40PM +0800, Zhang Chen wrote:
> From: Zhang Chen
>
> Xen COLO and KVM COLO shared lots of code in Qemu.
> The colo-compare object in Qemu now requires an 'iothread' property since
> QEMU 2.11.
>
> Detail:
> https://wiki.qemu.org/Features/COLO
>
> Signed-off-by:
> On 26 Jul 2019, at 08:17, Roger Pau Monné wrote:
>
> On Thu, Jul 25, 2019 at 03:08:07PM -0400, Rich Persaud wrote:
>> (cc Intel and tboot-devel)
>>
>> Hi Roger,
>>
>> Thanks for your interest in documenting the status of maintenance for Intel
>> TXT support in Xen. Intel TXT and Xen are
On Wed, Jul 10, 2019 at 04:05:02PM +0200, Laszlo Ersek wrote:
> On 07/04/19 16:42, Anthony PERARD wrote:
> > +
> > +STATIC
> > +VOID
> > +EFIAPI
> > +XenIoPvhDxeNotifyExitBoot (
> > + IN EFI_EVENT Event,
> > + IN VOID *Context
> > + )
> > +{
> > + XEN_IO_PVH_STATE *State;
> > +
On 26/07/2019 16:48, Viktor Mitin wrote:
Hi All,
On Thu, Jul 18, 2019 at 5:45 PM Tamas K Lengyel wrote:
Checking the comment styles are not included in the automation.
The same about clang-format. Checking the comment styles is not supported.
It seems this is not code format checker task
Hi All,
On Thu, Jul 18, 2019 at 5:45 PM Tamas K Lengyel wrote:
> Checking the comment styles are not included in the automation.
The same about clang-format. Checking the comment styles is not supported.
It seems this is not code format checker task to parse and modify the
code comments...
From: Zhang Chen
Xen COLO and KVM COLO shared lots of code in Qemu.
The colo-compare object in Qemu now requires an 'iothread' property since QEMU
2.11.
Detail:
https://wiki.qemu.org/Features/COLO
Signed-off-by: Zhang Chen
---
tools/libxl/libxl_dm.c | 5 -
1 file changed, 4
On Fri, Jul 26, 2019 at 9:12 AM Julien Grall wrote:
>
> Hi Viktor,
>
> On 26/07/2019 15:58, Viktor Mitin wrote:
> > On Fri, Jul 19, 2019 at 11:37 AM Julien Grall wrote:
> >>
> >> Hi Tamas,
> >>
> >> On 18/07/2019 18:22, Tamas K Lengyel wrote:
> - Line 139: The { are commonly on the
On Fri, Jul 26, 2019 at 03:45:22PM +0100, Andrew Cooper wrote:
> On 26/07/2019 15:38, Roger Pau Monné wrote:
> > On Fri, Jul 26, 2019 at 02:52:40PM +0100, Andrew Cooper wrote:
> >> The XPTI work restricted the visibility of most of memory, but missed a few
> >> aspects when it came to the TSS.
>
Hi Viktor,
On 26/07/2019 15:58, Viktor Mitin wrote:
On Fri, Jul 19, 2019 at 11:37 AM Julien Grall wrote:
Hi Tamas,
On 18/07/2019 18:22, Tamas K Lengyel wrote:
- Line 139: The { are commonly on the same line as struct or definition.
According to CODING_STYLE that's not how it should
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: Friday, July 26, 2019 10:34 PM
> To: Zhang, Chen
> Cc: Ian Jackson ; Wei Liu ; xen-
> de...@lists.xenproject.org; Zhang Chen
> Subject: Re: [PATCH V2] tools/libxl: Add iothread support for COLO
>
>
On Fri, Jul 19, 2019 at 11:37 AM Julien Grall wrote:
>
> Hi Tamas,
>
> On 18/07/2019 18:22, Tamas K Lengyel wrote:
> >> - Line 139: The { are commonly on the same line as struct or
> >> definition.
> >
> > According to CODING_STYLE that's not how it should be.
>
> I guess you refer to the
lOn 26/07/2019 15:49, Viktor Mitin wrote:
Hi Julien, All,
Hi,
On Thu, Jul 18, 2019 at 6:44 PM Julien Grall wrote:
Hi Tamas,
On 7/18/19 4:14 PM, Tamas K Lengyel wrote:
On Thu, Jul 18, 2019 at 9:02 AM Julien Grall wrote:
Hi Tamas,
Adding Lars, Artem and Iurii. Iurii has been working
Please be aware that such for_each_* cases are covered by clang-format.
Thanks
On Thu, Jul 18, 2019 at 8:50 PM Tamas K Lengyel wrote:
>
> >- Line 1025: The tools needs to be able to deal for_each_vcpu(...) & co.
>
> These can be made OK by adding braces. Other than that the only way I
>
Hi All,
On Thu, Jul 18, 2019 at 8:24 PM Tamas K Lengyel wrote:
>
> >- Line 139: The { are commonly on the same line as struct or definition.
>
> According to CODING_STYLE that's not how it should be.
All such cases should be explicitly stated in the CODING_STYLE document.
Thanks
> Tamas
>
> -Original Message-
> From: Jan Beulich
> Sent: 26 July 2019 15:34
> To: Paul Durrant
> Cc: xen-devel (xen-devel@lists.xenproject.org)
>
> Subject: Re: [Xen-devel] per-domain passthrough/iommu options
>
> On 26.07.2019 16:26, Paul Durrant wrote:
> >> From: Jan Beulich
> >> Sent: 26
On Fri, Jul 26, 2019 at 8:42 AM Viktor Mitin wrote:
>
> Hi All,
>
> On Thu, Jul 18, 2019 at 6:16 PM Jan Beulich wrote:
> >
> > On 18.07.2019 16:43, Tamas K Lengyel wrote:
> > > --- a/CODING_STYLE
> > > +++ b/CODING_STYLE
> > > @@ -60,8 +60,8 @@ Bracing
> > > ---
> > >
> > > Braces ('{'
On 26/07/2019 15:38, Jan Beulich wrote:
> On 26.07.2019 16:30, Andrew Cooper wrote:
>> On 26/07/2019 15:22, Roger Pau Monné wrote:
>>> On Fri, Jul 26, 2019 at 02:52:39PM +0100, Andrew Cooper wrote:
Future changes are going to need to page align some percpu data.
This means that the
Hi Julien, All,
On Thu, Jul 18, 2019 at 6:44 PM Julien Grall wrote:
>
> Hi Tamas,
>
> On 7/18/19 4:14 PM, Tamas K Lengyel wrote:
> > On Thu, Jul 18, 2019 at 9:02 AM Julien Grall wrote:
> >>
> >> Hi Tamas,
> >>
> >> Adding Lars, Artem and Iurii. Iurii has been working on a version for
> >>
On 26/07/2019 15:38, Roger Pau Monné wrote:
> On Fri, Jul 26, 2019 at 02:52:40PM +0100, Andrew Cooper wrote:
>> The XPTI work restricted the visibility of most of memory, but missed a few
>> aspects when it came to the TSS.
>>
>> Given that the TSS is just an object in percpu data, the 4k mapping
On 26.07.2019 16:26, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 26 July 2019 15:02
>>
>> On 26.07.2019 15:39, Paul Durrant wrote:
>>> ? I don't think 'private-pt' or 'separate-pt' really capture the fact that
>>> the page tables match the
>> P2M. They could just as easily be taken to mean
On 23/07/2019 22:35, Julien Grall wrote:
The definition of PRIregister varies between Arm32 and Arm64 (32-bit vs
64-bit). However, some of the users uses the wrong padding.
For more consistency, the padding is now moved into the PRIregister and
varies depending on the architecture.
Below a
On 26.07.2019 16:30, Andrew Cooper wrote:
> On 26/07/2019 15:22, Roger Pau Monné wrote:
>> On Fri, Jul 26, 2019 at 02:52:39PM +0100, Andrew Cooper wrote:
>>> Future changes are going to need to page align some percpu data.
>>>
>>> This means that the percpu area needs suiably aligning in the BSS
Hi All,
On Thu, Jul 18, 2019 at 6:16 PM Jan Beulich wrote:
>
> On 18.07.2019 16:43, Tamas K Lengyel wrote:
> > --- a/CODING_STYLE
> > +++ b/CODING_STYLE
> > @@ -60,8 +60,8 @@ Bracing
> > ---
> >
> > Braces ('{' and '}') are usually placed on a line of their own, except
> > -for the
On Fri, Jul 26, 2019 at 02:52:40PM +0100, Andrew Cooper wrote:
> The XPTI work restricted the visibility of most of memory, but missed a few
> aspects when it came to the TSS.
>
> Given that the TSS is just an object in percpu data, the 4k mapping for it
> created in setup_cpu_root_pgt() maps
On 26/07/2019 15:21, Volodymyr Babchuk wrote:
Julien Grall writes:
Hi,
On 26/07/2019 13:47, Volodymyr Babchuk wrote:
Julien Grall writes:
The definition of PRIregister varies between Arm32 and Arm64 (32-bit vs
64-bit). However, some of the users uses the wrong padding.
type: "users
On Fri, Jul 26, 2019 at 02:18:42PM +, Zhang, Chen wrote:
>
> > -Original Message-
> > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > Sent: Friday, July 26, 2019 9:48 PM
> >
> > On Fri, Jul 26, 2019 at 02:43:00PM +0800, Zhang Chen wrote:
> > What I had in mind while
On 26/07/2019 15:22, Roger Pau Monné wrote:
> On Fri, Jul 26, 2019 at 02:52:39PM +0100, Andrew Cooper wrote:
>> Future changes are going to need to page align some percpu data.
>>
>> This means that the percpu area needs suiably aligning in the BSS so CPU0 has
>> correctly aligned data. Shuffle
Julien Grall writes:
> The return address of a function is always stored in x30. For convenience,
> introduce a register alias so "lr" can be used in assembly.
>
> This is defined in asm-arm/arm64/macros.h to allow all assembly files
> to use it.
>
> Signed-off-by: Julien Grall
Reviewed-by:
> -Original Message-
> From: Jan Beulich
> Sent: 26 July 2019 15:02
> To: Paul Durrant
> Cc: xen-devel (xen-devel@lists.xenproject.org)
>
> Subject: Re: [Xen-devel] per-domain passthrough/iommu options
>
> On 26.07.2019 15:39, Paul Durrant wrote:
> > Not sure how 'on' would co-exist
On Fri, Jul 26, 2019 at 02:52:39PM +0100, Andrew Cooper wrote:
> Future changes are going to need to page align some percpu data.
>
> This means that the percpu area needs suiably aligning in the BSS so CPU0 has
> correctly aligned data. Shuffle the exact link order of items within the BSS
> to
> On 26 Jul 2019, at 15:17, Viktor Mitin wrote:
>
> On Fri, Jul 26, 2019 at 4:52 PM Lars Kurth wrote:
thank you for putting this mail together and driving this forward. I added
committers@ as well as Doug. I am going to let others respond first.
I am assuming we are looking
Julien Grall writes:
> Hi,
>
> On 26/07/2019 13:47, Volodymyr Babchuk wrote:
>>
>> Julien Grall writes:
>>
>>> The definition of PRIregister varies between Arm32 and Arm64 (32-bit vs
>>> 64-bit). However, some of the users uses the wrong padding.
>> type: "users use"
>>
>>> For more consistency,
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: Friday, July 26, 2019 9:48 PM
> To: Zhang, Chen
> Cc: Ian Jackson ; Wei Liu ; xen-
> de...@lists.xenproject.org; Zhang Chen
> Subject: Re: [PATCH V2] tools/libxl: Add iothread support for COLO
>
> On
On Fri, Jul 26, 2019 at 4:52 PM Lars Kurth wrote:
> >> thank you for putting this mail together and driving this forward. I added
> >> committers@ as well as Doug. I am going to let others respond first.
> >> I am assuming we are looking for some testing?
> >
> > Yes, you are right.
> > The
Julien Grall writes:
> Hi,
>
> On 26/07/2019 13:31, Volodymyr Babchuk wrote:
>>
>> Julien Grall writes:
>>
>>> psr_mode_is_32bit() prototype does not match the rest of the helpers for
>>> the process state. Looking at the callers, most of them will access
>>> struct cpu_user_regs just for
On 26.07.2019 15:39, Paul Durrant wrote:
> Not sure how 'on' would co-exist with 'viommu'... the crucial difference is
> whether the p2m is shared or not and the currently the only option in the
> non-shared case, because we lack a viommu, is to keep the IOMMU mappings in
> sync with the P2M
Hi,
It looks like the vmap solution suggested by Andrew & I is a dead end. I still
think we need to do something in the vmap regardless the alignment decision to
avoid unwanted surprised (i.e the Page-table not in sync with the vmap state).
We potentially want to add some
Hi Jan, All,
On Thu, Jul 18, 2019 at 4:38 PM Jan Beulich wrote:
> >> But you're actively breaking Xen style here (and below).
> >
> > I don't see any mention of style restrictions regarding this in
> > CODING_STYLE. If there is, I would prefer changing that so we can
> > automate style checks
> On 26 Jul 2019, at 14:45, Viktor Mitin wrote:
>
>> Hi Viktor,
>
> Hi Lars,
>
>> thank you for putting this mail together and driving this forward. I added
>> committers@ as well as Doug. I am going to let others respond first.
>> I am assuming we are looking for some testing?
>
> Yes,
Future changes are going to need to page align some percpu data.
This means that the percpu area needs suiably aligning in the BSS so CPU0 has
correctly aligned data. Shuffle the exact link order of items within the BSS
to give .bss.percpu.page_aligned appropriate alignment.
Additionally,
The XPTI work restricted the visibility of most of memory, but missed a few
aspects when it came to the TSS.
Given that the TSS is just an object in percpu data, the 4k mapping for it
created in setup_cpu_root_pgt() maps adjacent percpu data, making it all
leakable via Meltdown, even when XPTI is
Andrew Cooper (2):
xen/link: Introduce .bss.percpu.page_aligned
x86/xpti: Don't leak TSS-adjacent percpu data via Meltdown
xen/arch/arm/xen.lds.S | 5 +++--
xen/arch/x86/setup.c| 2 --
xen/arch/x86/traps.c| 6 ++
xen/arch/x86/xen.lds.S | 7
Hi Julien,
> I have already done some testings a couple of weeks ago with the patch [1]. I
> have sent some comments regarding the change made by the tools that require
> some
> attention. It would be good if someone go through them and try to address one
> by
> one. For convenience I have
On Fri, Jul 26, 2019 at 02:43:00PM +0800, Zhang Chen wrote:
> From: Zhang Chen
>
> Xen COLO and KVM COLO shared lots of code in Qemu.
> KVM COLO has added the iothread support, so we add it on Xen.
It would be useful to expand the comment of the commit and explain why the
change is required. I
On 26/07/2019 14:34, Jan Beulich wrote:
> The #include was added by 0700c962ac ("Add AMD IOMMU support into
> hypervisor") and I then didn't drop it again in d7f913b8de ("AMD IOMMU:
> use ioremap()"); similarly for xen/iommu.h in 99321e0e6c ("VT-d: use
> ioremap()"). Avoid needlessly re-building
> Hi Viktor,
Hi Lars,
> thank you for putting this mail together and driving this forward. I added
> committers@ as well as Doug. I am going to let others respond first.
> I am assuming we are looking for some testing?
Yes, you are right.
The implementation has been updated and retested with
The #include was added by 0700c962ac ("Add AMD IOMMU support into
hypervisor") and I then didn't drop it again in d7f913b8de ("AMD IOMMU:
use ioremap()"); similarly for xen/iommu.h in 99321e0e6c ("VT-d: use
ioremap()"). Avoid needlessly re-building unrelated files when only
IOMMU definitions have
> -Original Message-
> From: Jan Beulich
> Sent: 26 July 2019 13:57
> To: Paul Durrant
> Cc: xen-devel (xen-devel@lists.xenproject.org)
>
> Subject: Re: [Xen-devel] per-domain passthrough/iommu options
>
> On 26.07.2019 14:29, Paul Durrant wrote:
> >I sent a previous email [1]
Hello,
Current Xen build system will ignore any toolchain related variables on
the environment when building (ie: CC, LD, CXX...), and the only way to
set those is to assign them directly on the make command line (ie: make
CC=foo CXX=bar ...).
The following series attempts to fix this, by
Include config/$(OS).mk which contains the default values for the
toolchain variables. This removes the need to pass HOST{CC/CXX} as
parameters from the high level make target or to default them to
gcc/g++ if unset.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian
Don't force the usage of the hardcoded compiler values if those are
already set on the environment. This allows the Xen build system to
correctly pick CC/CXX values present on the environment, and fixes the
usage of those by the Gitlab CI test system.
Note that without this fix the Xen build
Don't force the usage of the hardcoded toolchain values if those are
already set on the environment.
Note that as part of the change the definition of AS and LD is moved
after the setting of compiler related variables.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc:
Viktor Mitin writes:
> Hi Volodymyr,
>
> On Fri, Jul 26, 2019 at 2:57 PM Volodymyr Babchuk
> wrote:
>>
>>
>> Hello Vikor,
>>
>> Viktor Mitin writes:
>>
>> > xen/arm: extend fdt_property_interrupts to deal with other
>> > domain than the hwdom
>>
>> It is unclear what problem you are facing.
Hi,
On 26/07/2019 13:47, Volodymyr Babchuk wrote:
Julien Grall writes:
The definition of PRIregister varies between Arm32 and Arm64 (32-bit vs
64-bit). However, some of the users uses the wrong padding.
type: "users use"
For more consistency, the padding is now moved into the PRIregister
Julien Grall writes:
> On 26/07/2019 13:14, Volodymyr Babchuk wrote:
>>
>> Hi Julien,
>
> Hi Volodymyr,
>
>> Julien Grall writes:
>>
>>> Currently, the structure vcpu_guest_core_regs is part of the public API.
>>> This implies that any change in the structure should be backward
>>> compatible.
On 26/07/2019 14:10, Tamas K Lengyel wrote:
> On Fri, Jul 26, 2019 at 6:58 AM Andrew Cooper
> wrote:
>> On 26/07/2019 13:55, Tamas K Lengyel wrote:
>>> On Fri, Jul 26, 2019 at 4:11 AM Andrew Cooper
>>> wrote:
* Add a dependency so the shim gets rebuilt when pvshim_defconfig changes.
On Fri, Jul 26, 2019 at 6:58 AM Andrew Cooper wrote:
>
> On 26/07/2019 13:55, Tamas K Lengyel wrote:
> > On Fri, Jul 26, 2019 at 4:11 AM Andrew Cooper
> > wrote:
> >> * Add a dependency so the shim gets rebuilt when pvshim_defconfig changes.
> >> * Default to the NULL scheduler now that it
Hi,
On 26/07/2019 13:31, Volodymyr Babchuk wrote:
Julien Grall writes:
psr_mode_is_32bit() prototype does not match the rest of the helpers for
the process state. Looking at the callers, most of them will access
struct cpu_user_regs just for calling psr_mode_is_32bit().
The macro is now
flight 139358 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139358/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 139303
On 26.07.19 15:15, Dario Faggioli wrote:
Yep, I think being able to know time spent running guests could be
useful.
Well, my intention was to see hypervisor run and true idle time.
With this full series I see the distinct difference in xentop depending on the
type of load in domains:
On
On 26.07.2019 14:29, Paul Durrant wrote:
>I sent a previous email [1] about enabling use of the IOMMU on a
> per-domain basis and am now a reasonable way into my patch series, which also
> allows for IOMMU option-setting (specifically shared EPT use) on a per-domain
> basis too. Before I
On 26/07/2019 13:55, Tamas K Lengyel wrote:
> On Fri, Jul 26, 2019 at 4:11 AM Andrew Cooper
> wrote:
>> * Add a dependency so the shim gets rebuilt when pvshim_defconfig changes.
>> * Default to the NULL scheduler now that it works with vcpu online/offline.
>>
>> Signed-off-by: Andrew Cooper
>>
On Fri, Jul 26, 2019 at 4:11 AM Andrew Cooper wrote:
>
> * Add a dependency so the shim gets rebuilt when pvshim_defconfig changes.
> * Default to the NULL scheduler now that it works with vcpu online/offline.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Wei Liu
> CC: Roger
On 26/07/2019 13:14, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
Julien Grall writes:
Currently, the structure vcpu_guest_core_regs is part of the public API.
This implies that any change in the structure should be backward
compatible.
However, the structure is only needed by the
On 26/07/2019 13:42, Lars Kurth wrote:
Hi Viktor,
Hi,
thank you for putting this mail together and driving this forward. I added
committers@ as well as Doug. I am going to let others respond first.
I am assuming we are looking for some testing?
I have already done some testings a couple
Julien Grall writes:
> The definition of PRIregister varies between Arm32 and Arm64 (32-bit vs
> 64-bit). However, some of the users uses the wrong padding.
type: "users use"
> For more consistency, the padding is now moved into the PRIregister and
> varies depending on the architecture.
I'm
Hi Volodymyr,
On Fri, Jul 26, 2019 at 2:57 PM Volodymyr Babchuk
wrote:
>
>
> Hello Vikor,
>
> Viktor Mitin writes:
>
> > xen/arm: extend fdt_property_interrupts to deal with other
> > domain than the hwdom
>
> It is unclear what problem you are facing. Could you please elaborate
> commit
Julien Grall writes:
> On Arm64, the SMCCC function identifier is always stored in the first 32-bit
> of x0 register. The rest of the bits are not defined and should be
> ignored.
>
> This means the variable funcid should be an uint32_t rather than
> register_t.
>
> Signed-off-by: Julien Grall
Julien Grall writes:
> At the moment, do_trap_brk() is using a BUG_ON() to check the hardware
> has been correctly configured during boot.
>
> Any error when configuring the hardware could result to a guest 'brk'
> trapping in the hypervisor and crash it.
>
> This is pretty harsh to kill Xen
Hi,
I sent a previous email [1] about enabling use of the IOMMU on a per-domain
basis and am now a reasonable way into my patch series, which also allows for
IOMMU option-setting (specifically shared EPT use) on a per-domain basis too.
Before I post v1 I'd like to get some opinion on the
Hello Dario,
On 26.07.19 15:00, Dario Faggioli wrote:
On Fri, 2019-07-26 at 13:37 +0300, Andrii Anisov wrote:
From: Andrii Anisov
Currently the idle time is being accounted as a idle vcpu runtime.
This is not entirely correct, because the entity named idle vcpu is
in fact a hypervisor tasks
Julien Grall writes:
> psr_mode_is_32bit() prototype does not match the rest of the helpers for
> the process state. Looking at the callers, most of them will access
> struct cpu_user_regs just for calling psr_mode_is_32bit().
>
> The macro is now reworked to take a struct cpu_user_regs in
> On 26 Jul 2019, at 13:30, Viktor Mitin wrote:
>
> Hi All,
>
> The Xen Project has a coding standard in place, but like many
> projects, the standard is only enforced through peer review. Such
> mistakes slip through and code is imported from other projects which
> may not follow the same
flight 139352 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139352/
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.
Julien Grall writes:
> At the moment, _show_registers() is using a BUG_ON() to assert only
> userspace will run 32-bit code in a 64-bit domain.
>
> Such extra precaution is not necessary and could be avoided by only
> checking the CPU mode to decide whether show_registers_64() or
>
1 - 100 of 153 matches
Mail list logo
