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
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;
> > + EFI_STAT
> 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 d
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: Zh
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 f
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
we
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 d78b126a34d
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 dependi
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 (XE
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
test-amd64-i386-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 I'm
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 1
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
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 nee
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|
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 no
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 --
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: Volodymyr
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:
https://lore.kernel.org/xen-devel/20190726203222.4833-1-andrew.coop...@citrix.c
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é
CC:
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 .bss.percpu.p
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 i
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
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,
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.
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.
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
test-amd64-amd
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 520a1e60de4341f55c59c
flight 139367 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139367/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 139338
Tests which did not
Hi team,
I am beginner for XEN platform and curious to know how to assign specific CPU
to dom0 and domU?
Could you please provide me any relevant link for same? I have two CPU ARCH
Cortex -A57 and Cortex A-53 and I want to assign dom0 to Cortex -A57 and cross
check that Is it assign to same or
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 deployed in production today by
> OpenXT and QubesOS for boot int
On 19.07.19 02:58, Nadav Amit wrote:
To improve TLB shootdown performance, flush the remote and local TLBs
concurrently. Introduce flush_tlb_multi() that does so. Introduce
paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen
and hyper-v are only compile-tested).
While the upd
>>> On 27.06.19 at 20:56, wrote:
> GCC 5 introduced -fsanitize=alignment which is enabled by default by
> CONFIG_UBSAN. This trips a load of wont-fix cases in the ACPI tables and the
> hypercall page and stubs writing logic.
>
> It also causes the native Xen boot to crash before the console is s
flight 139342 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139342/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139259
test-amd64-i386-xl-qemuu-win7-amd64
Hello Kumar,
On 26.07.19 09:26, Raushan Kumar wrote:
Could you please provide me any relevant link for same? I have two CPU ARCH
Cortex –A57 and Cortex A-53 and I want to assign dom0 to Cortex –A57 and cross
check that Is it assign to same or not?
As long as you have big.LITTLE on your site
On 23.07.2019 20:25, Roman Shaposhnik wrote:
> Interestingly enough, adding iommu_inclusive_mapping=1 AND iommu=debug
> booted the system just fine.
Btw (I've noticed this only now) - are you saying without "iommu=debug"
the box does _not_ boot fine, despite the other option?
Jan
On 25.07.2019 21:08, Rich Persaud wrote:
> Since we have at least one Intel maintainer, Lukasz, the feature need not be
> orphaned. If Shawn is not responding to the request to confirm Lukasz as
> maintainer, the Xen community has multiple communication channels with Intel.
> Pragmatically, a revi
xen/arm: extend fdt_property_interrupts to deal with other
domain than the hwdom
Tested with aarch64 qemu dom0 and dom0less boot.
Suggested-by: Julien Grall
Signed-off-by: Viktor Mitin
---
See discussion in mail:
[PATCH] xen/arm: merge make_timer_node and make_timer_domU_node
xen/arch/arm/d
On 25/07/2019 11:03, Jan Beulich wrote:
> On 25.07.2019 02:53, christopher.w.cl...@gmail.com wrote:
>> gcc 9.1.0 reports:
>>
>> | test-cpu-policy.c:64:18: error: '%.12s' directive argument is not a
>> nul-terminated string [-Werror=format-overflow=]
>> |64 | fail(" Test '%.12s', e
On Thu, Jul 25, 2019 at 05:47:19PM -0700, Roman Shaposhnik wrote:
> Hi Roger!
>
> With your patch (and build as a debug build) Xen crashes on boot
> (which I guess was the point of your BUG_ON statement).
Yes, that's very weird, seems like entries are not added to the iommu
page tables but I have
On Thu, 2019-07-25 at 10:25 +0200, Roger Pau Monné wrote:
> On Wed, Jul 24, 2019 at 05:53:26PM -0700,
> christopher.w.cl...@gmail.com wrote:
> > From: Christopher Clark
> >
> > diff --git a/tools/tests/cpu-policy/test-cpu-policy.c
> > b/tools/tests/cpu-policy/test-cpu-policy.c
> > index ca3b8dd4
On 24/07/2019 12:26, Juergen Gross wrote:
> diff --git a/xen/common/wait.c b/xen/common/wait.c
> index 4f830a14e8..3fc5f68611 100644
> --- a/xen/common/wait.c
> +++ b/xen/common/wait.c
> @@ -34,8 +34,6 @@ struct waitqueue_vcpu {
> */
> void *esp;
> char *stack;
> -cpumask_t save
On 26.07.19 11:46, Andrew Cooper wrote:
On 24/07/2019 12:26, Juergen Gross wrote:
diff --git a/xen/common/wait.c b/xen/common/wait.c
index 4f830a14e8..3fc5f68611 100644
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -34,8 +34,6 @@ struct waitqueue_vcpu {
*/
void *esp;
char
The openSUSE Leap container image, built after
opensuse-leap.dockerfile was missing the gcc-c++,
which is necessary, e.g., for building OVMF.
Add it.
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
---
automation/build/suse/opensuse-leap.dockerfile |1 +
1 file changed, 1 insertion(+)
On Fri, Jul 26, 2019 at 02:24:23AM +0200, Dario Faggioli wrote:
> Hey,
Hi,
> openSUSE Tumbleweed has: gcc version 9.1.1 20190703
>
> And this fails to build QEMU, like this:
I'm sorry I have to ask, which version of QEMU or qemu-xen are speaking
about? I'm pretty sure it's unstable, but it's be
* 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 Pau Monné
CC: Juergen Gross
CC: Dario Faggioli
This patch depends on
On 26/07/2019 10:53, Juergen Gross wrote:
> On 26.07.19 11:46, Andrew Cooper wrote:
>> On 24/07/2019 12:26, Juergen Gross wrote:
>>> diff --git a/xen/common/wait.c b/xen/common/wait.c
>>> index 4f830a14e8..3fc5f68611 100644
>>> --- a/xen/common/wait.c
>>> +++ b/xen/common/wait.c
>>> @@ -34,8 +34,6
On 26.07.19 12:13, Andrew Cooper wrote:
On 26/07/2019 10:53, Juergen Gross wrote:
On 26.07.19 11:46, Andrew Cooper wrote:
On 24/07/2019 12:26, Juergen Gross wrote:
diff --git a/xen/common/wait.c b/xen/common/wait.c
index 4f830a14e8..3fc5f68611 100644
--- a/xen/common/wait.c
+++ b/xen/common/wa
From: Andrii Anisov
This is the very RFC series, which is aimed to address some of VCPU time
accounting problems which affect scheduling fairness and accuracy. Please
note that this is done for ARM64 yet.
One of the scheduling problems is a misleading CPU idle time concept. Now
for the CPU idle
From: Julien Grall
This makes function enter_hypervisor_head() being executed with
irqs locked.
Signed-off-by: Julien Grall
[Andrii: add a justification commit message]
Signed-off-by: Andrii Anisov
---
xen/arch/arm/arm64/entry.S | 11 +--
xen/arch/arm/traps.c | 6 ++
2 file
From: Andrii Anisov
Extend XEN_SYSCTL_getcpuinfo interface with guest and hypervisor
time information.
Signed-off-by: Andrii Anisov
---
xen/common/schedule.c | 22 ++
xen/common/sysctl.c | 2 ++
xen/include/public/sysctl.h | 2 ++
xen/include/xen/sched.h
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 worker. E.g. some softirqs are processed
by the idle vcpu.
So lets change idle vcpu time accounting and specify sys
From: Andrii Anisov
On ARM64 we know exactly if trap happened from hypervisor or guest, so
we do not need to take that decision. This reduces a condition for
all enter_hypervisor_head calls and the function call for traps from
the hypervisor mode.
Currently, it is implemented for ARM64 only. Int
From: Andrii Anisov
Account for a guest:
- guest running time
- guest sync traps serving time (hypercalls, trapped emulated iomems, etc)
- vcpu jobs in leave_hypervisor_tail
Account for the hyp:
- IRQ processing
- Softirq processing
Signed-off-by: Andrii Anisov
---
xen/arch/arm/traps.c
From: Andrii Anisov
On ARM64 we know exactly if trap happened from hypervisor or guest, so
we do not need to take that decision. This reduces a condition for
all enter_hypervisor_head calls and the function call for traps from
the hypervisor mode.
Currently, it is implemented for ARM64 only. Int
From: Andrii Anisov
Let xentop request and show information about CPU load
(hypervisor, guest and idle information)
Signed-off-by: Andrii Anisov
---
tools/xenstat/libxenstat/src/xenstat.c | 38 +
tools/xenstat/libxenstat/src/xenstat.h | 9 +++
tools/x
flight 139348 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139348/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are fail
Sorry guys,
I was eliminating cyrillic "с" in the commit title and occasionally left this
patch in the folder.
Please ignore exactly this patch.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenp
Hi,
On 26/07/2019 11:37, Andrii Anisov wrote:
From: Julien Grall
This makes function enter_hypervisor_head() being executed with
irqs locked.
This is the 3rd time you send this patch... and still no proper explanation why
this is done nor the impact on keeping the interrupts disabled longer
flight 139357 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139357/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 520a1e60de4341f55c59cf4680d6d0242a7f929f
baseline version:
ovmf 0dd8d7d556df46c503254
On 26.07.19 12:10, 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 Pau Monné
CC: Juergen Gross
C
Hi,
On 26/07/2019 11:37, Andrii Anisov wrote:
From: Andrii Anisov
On ARM64 we know exactly if trap happened from hypervisor or guest, so
we do not need to take that decision. This reduces a condition for
all enter_hypervisor_head calls and the function call for traps from
the hypervisor mode.
Hi team,
Thank you for quick response. However, this explanation is not for my question.
I want to assign dom0 to Cortex A-57 and my machine has 3-4 CPU of ARM
architecture , Could you please aware me what is the procedure ?
I already gone through the your wiki, but do not get relevant answer.
flight 139365 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139365/
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 1
On 26.07.2019 11:46, Andrew Cooper wrote:
> On 24/07/2019 12:26, Juergen Gross wrote:
>> @@ -182,30 +178,24 @@ static void __prepare_to_wait(struct waitqueue_vcpu
>> *wqv)
>> static void __finish_wait(struct waitqueue_vcpu *wqv)
>> {
>> wqv->esp = NULL;
>> -(void)vcpu_set_hard_affini
On 26.07.19 13:35, Jan Beulich wrote:
On 26.07.2019 11:46, Andrew Cooper wrote:
On 24/07/2019 12:26, Juergen Gross wrote:
@@ -182,30 +178,24 @@ static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
static void __finish_wait(struct waitqueue_vcpu *wqv)
{
wqv->esp = NULL;
-(v
On 26/07/2019 12:42, Juergen Gross wrote:
> On 26.07.19 13:35, Jan Beulich wrote:
>> On 26.07.2019 11:46, Andrew Cooper wrote:
>>> On 24/07/2019 12:26, Juergen Gross wrote:
@@ -182,30 +178,24 @@ static void __prepare_to_wait(struct
waitqueue_vcpu *wqv)
static void __finish_wait(st
[Adding George plus others x86, ARM and core-Xen people]
Hi Andrii,
First of all, thanks a lot for this series!
The problem you mention is a long standing one, and I'm glad we're
eventually starting to properly look into it.
I already have one comment: I think I can see from where this come
fro
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 message?
Also, looks like your commit message is formatted incorrectly.
> Tested with aarch64 qem
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 worker. E.g. some softirqs are processed
> by the
Hi Julien,
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 tools and Xen. It is also
> not expected to be ever used ou
On 26.07.19 13:56, Dario Faggioli wrote:
[Adding George plus others x86, ARM and core-Xen people]
Hi Andrii,
First of all, thanks a lot for this series!
The problem you mention is a long standing one, and I'm glad we're
eventually starting to properly look into it.
I already have one comment:
On Fri, 2019-07-26 at 13:37 +0300, Andrii Anisov wrote:
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 0a38d4a..9e8805d 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -217,6 +217,28 @@ uint64_t get_cpu_idle_time(unsigned int cpu)
> return state.ti
Hi,
Julien Grall writes:
> On Arm64, system registers are always 64-bit including SCTLR_EL1.
> However, Xen is assuming this is 32-bit because earlier revision of
> Armv8 had the top 32-bit RES0 (see ARM DDI0595.b).
>
> From Armv8.5, some bits in [63:32] will be defined and allowed to be
> modif
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 standard. The goal would be to come up with a
tool that can audit the
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
> show_reigsters
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.
> 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 sta
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 parame
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 what
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 w
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 when
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
R
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 message?
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 not
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
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 to
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 Pa
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 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 pos
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 my
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
test-arm64-arm64-libvir
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 rewo
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 works
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.
*
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.
>>
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 a
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. Coul
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:
1 - 100 of 147 matches
Mail list logo
