flight 128580 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128580/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 128493
test-amd64-i386-xl-q
On Fri, 2018-10-12 at 07:15 +0200, Juergen Gross wrote:
> On 11/10/2018 19:37, Dario Faggioli wrote:
> >
> > So, for example:
> > - domain A has vCore0 and vCore1
> > - each vCore has 2 threads ({vCore0.0, vCore0.1} and
> > {vCore1.0, vCore1.1})
> > - we're on a 2-way SMT host
> > - vCore1 is ru
On 12/10/2018 09:49, Dario Faggioli wrote:
> On Fri, 2018-10-12 at 07:15 +0200, Juergen Gross wrote:
>> On 11/10/2018 19:37, Dario Faggioli wrote:
>>>
>>> So, for example:
>>> - domain A has vCore0 and vCore1
>>> - each vCore has 2 threads ({vCore0.0, vCore0.1} and
>>> {vCore1.0, vCore1.1})
>>> -
On Fri, 2018-10-12 at 10:35 +0200, Juergen Gross wrote:
> On 12/10/2018 09:49, Dario Faggioli wrote:
> >
> > But how easy it is to opt out, if one doesn't want it? E.g., in the
> > context of L1TF, what if I'm not affected, and hence am not
> > interested
> > in core-scheduling? What if I want a c
On 12/10/2018 11:15, Dario Faggioli wrote:
> On Fri, 2018-10-12 at 10:35 +0200, Juergen Gross wrote:
>> On 12/10/2018 09:49, Dario Faggioli wrote:
>>>
>>> But how easy it is to opt out, if one doesn't want it? E.g., in the
>>> context of L1TF, what if I'm not affected, and hence am not
>>> interest
In commit 303066fdb1e ("VMX: fix interaction of APIC-V and Viridian
emulation") I screwed up quite heavily: Instead of clearing SVI, RVI was
cleared. Furthermore, unconditional clearing of SVI is wrong too - other
ISR bits should be taken into account.
Introduce a new helper set_svi(), split out o
flight 75400 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75400/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
flight 128599 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128599/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 125898
test-amd
flight 128603 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128603/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128521
test-armhf-armhf-libvirt-raw 13 saveresto
>>> On 12.10.18 at 11:32, wrote:
> In commit 303066fdb1e ("VMX: fix interaction of APIC-V and Viridian
> emulation") I screwed up quite heavily: Instead of clearing SVI, RVI was
> cleared.
I was wrong here:
> @@ -2111,14 +2120,13 @@ static bool vmx_test_pir(const struct vc
> return pi_test_
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xen-freebsd
testid xen-build-freebsd
Tree: freebsd git://github.com/freebsd/freebsd.git
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 tre
flight 128662 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128662/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 128497
Tests which did
flight 128655 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128655/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7177be0bd8d372ef7eaa86df538bd45ec841ed23
baseline version:
ovmf 8122c6bc8b6f1fde31f2a
>>> On 09.10.18 at 10:25, wrote:
> Since commit 2c257bd6 "x86/hvm: remove default ioreq server (again)" the
> GFNs allocated by the toolstack and set in HVM_PARAM_IOREQ_PFN and
> HVM_PARAM_BUFIOREQ_PFN have been unused. This patch allows them to be used
> by (non-default) ioreq servers.
>
> While
>>> On 09.10.18 at 17:21, wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -161,8 +161,42 @@ string_param("badpage", opt_badpage);
> /*
> * no-bootscrub -> Free pages are not zeroed during boot.
> */
> -static bool_t opt_bootscrub __initdata = 1;
> -boolean_param("b
>>> On 04.10.18 at 17:43, wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -877,8 +877,25 @@ void watchdog_domain_destroy(struct domain *d);
>
> #define VM_ASSIST(d, t) (test_bit(VMASST_TYPE_ ## t, &(d)->vm_assist))
>
> -#define is_pv_domain(d) ((d)->guest_type == g
>>> On 04.10.18 at 17:43, wrote:
> This is useful to rewrite the following pattern (v is PV vcpu)
>
>if ( is_pv_32bit_vcpu(v) )
>do_foo;
>else
>do_bar;
>
> to
>
>if ( is_pv_32bit_vcpu(v) )
>do_foo;
>else if ( is_pv_64bit_vcpu(v) )
>do_bar;
>el
>>> On 04.10.18 at 17:43, wrote:
> Provide declarations for hypercall_page_initialise_ring*_kernel, make
> sure DCE work as expected.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https:
On 11/09/18 14:10, Jan Beulich wrote:
> Emulation requiring device model assistance uses a form of instruction
> re-execution, assuming that the second (and any further) pass takes
> exactly the same path. This is a valid assumption as far as use of CPU
> registers goes (as those can't change witho
>>> On 04.10.18 at 17:43, wrote:
> --- a/xen/arch/x86/hypercall.c
> +++ b/xen/arch/x86/hypercall.c
> @@ -248,6 +248,15 @@ int hypercall_xlat_continuation(unsigned int *id,
> unsigned int nr,
> return rc;
> }
>
> +#ifndef CONFIG_PV
> +/* Stub for arch_do_multicall_call */
> +enum mc_dispos
>>> On 04.10.18 at 17:43, wrote:
> The trap handlers in hypervisor need to forward events to PV guests if
> necessary. If there is no PV guest relevant code should be excluded.
>
> Put code under CONFIG_PV and add ASSERT_UNREACHABLE.
-ETOOMANYIFDEFS
What's wrong with an inline stub for pv_injec
>>> On 04.10.18 at 17:43, wrote:
> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
> @@ -509,8 +509,16 @@ int __init construct_dom0(struct domain *d, const
> module_t *image,
> }
> #endif
>
> -rc = (is_hvm_domain(d) ? dom0_construct_pvh : dom0_construct_pv)
> -
>>> On 04.10.18 at 17:43, wrote:
> It is used by PV code only.
And wrongly so - the same is needed for a PVH Dom0 afaict.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 12.10.18 at 15:55, wrote:
> On 11/09/18 14:10, Jan Beulich wrote:
>> Emulation requiring device model assistance uses a form of instruction
>> re-execution, assuming that the second (and any further) pass takes
>> exactly the same path. This is a valid assumption as far as use of CPU
>> reg
>>> On 04.10.18 at 17:43, wrote:
> --- a/xen/include/xen/compat.h
> +++ b/xen/include/xen/compat.h
> @@ -228,7 +228,16 @@ struct vcpu_runstate_info;
> void xlat_vcpu_runstate_info(struct vcpu_runstate_info *);
>
> struct domain;
> +
> +#ifdef CONFIG_PV
> int switch_compat(struct domain *);
>
On Fri, Oct 12, 2018 at 08:33:48AM -0600, Jan Beulich wrote:
> >>> On 04.10.18 at 17:43, wrote:
> > --- a/xen/include/xen/compat.h
> > +++ b/xen/include/xen/compat.h
> > @@ -228,7 +228,16 @@ struct vcpu_runstate_info;
> > void xlat_vcpu_runstate_info(struct vcpu_runstate_info *);
> >
> > struc
On Fri, Oct 05, 2018 at 05:29:30AM -0600, Jan Beulich wrote:
> This is not used (and probably was never meant to be) by the tool stack.
> Limiting it to the current domain in particular allows to eliminate a
> bogus use of vCPU 0 in pagetable_dying().
>
> Remove the now unnecessary domain/vCPU par
>>> On 04.10.18 at 17:43, wrote:
> Instead of trying to split up entry.S and compat/entry.S, simply
> provide some stubs for them.
I'm not convinced; I'd much rather see the call sites recognizably
compiled out with !PV. I'm curious what Andrew thinks here.
Jan
___
Juergen Gross writes ("Re: [Xen-devel] [PATCH 18/18] tools/debugger/kdd:
Install as `xen-kdd', not just `kdd'"):
> On 08/10/2018 16:01, Ian Jackson wrote:
> > Tim Deegan writes ("Re: [PATCH 18/18] tools/debugger/kdd: Install as
> > `xen-kdd', not just `kdd'"):
> >> At 18:29 +0100 on 05 Oct (15387
>>> On 04.10.18 at 17:43, wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -322,17 +322,34 @@ struct domain *domain_create(domid_t domid,
> }
>
> /* Sort out our idea of is_{pv,hvm}_domain(). */
> -if ( config && (config->flags & XEN_DOMCTL_CDF_hvm_guest) )
> +
This module should be called `libxenfsimage' for the same reasons that
the C library should.
Signed-off-by: Ian Jackson
---
v2: New in this version of the series
---
tools/pygrub/setup.py | 4 ++--
tools/pygrub/src/fsimage/fsimage.c | 8
tools/pygrub/src/pygrub|
`fsimage' is rather general. And we do not expect this library to be
very useful out of tree because of its unstable ABI.
So add the word `xen'. This will avoid naming conflicts with anyone
else's fsimage library.
Signed-off-by: Ian Jackson
---
v2: New in this version of the series
---
tools/
From: Hans van Kranenburg
libxenstore3.0 in Xen 4.8 had this function. We don't really want to
bump the ABI version (soname) just for this, since we don't think
there are actual callers anywhere. But tools complain about the
symbol going away.
So, provide a function xs_restrict which conforms
From: Ian Jackson
Adding the implementation language as a suffix to a program name is
poor practice.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
---
tools/xenmon/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/xenmon/Makefile b/tools/xenmon/Makefile
ind
This is v2 of my series of stuff from Debian. (I already pushed the
uncontroversial parts of v1, so those patches are now missing from
v2.) The remainder are build fixes, and addressing the namespace
pollution of the pygrub `fsimage' libraries by renaming it to
`xenfsimage'.
Hans van Kranenburg
These definitions were not properly protected from unwanted operator
precedence interactions.
Existing use sites in-tree all use & or |, so this does not change any
actual behaviour in-tree.
The same seems likely to be true in external callers.
Signed-off-by: Ian Jackson
---
v2: New in this ver
From: Ian Jackson
This allows the caller to provide some LDFLAGS to the Xen build
system.
Signed-off-by: Ian Jackson
---
tools/Rules.mk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 296b722372..68f2ed7ce1 100644
--- a/tools/Rules.mk
+++ b/tools/Rul
From: Ian Jackson
Firstly, add a reference to the documentation for the kconfig system.
Secondly, warn the user about the XEN_CONFIG_EXPERT problem.
CC: Wei Liu
CC: Andrew Cooper
CC: Jan Beulich
Signed-off-by: Ian Jackson
Reviewed-by: Doug Goldstein
---
v2: Fix typos
---
INSTALL | 20 +++
From: Ian Jackson
This command does the link, so it needs LDFLAGS.
Signed-off-by: Ian Jackson
---
tools/debugger/gdbsx/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/debugger/gdbsx/Makefile b/tools/debugger/gdbsx/Makefile
index 723a2743cc..8d7cd94a31 100644
From: Ian Jackson
`kdd' is an unfortunate namespace landgrab.
Signed-off-by: Ian Jackson
Acked-by: Tim Deegan
---
tools/debugger/kdd/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/debugger/kdd/Makefile b/tools/debugger/kdd/Makefile
index 5509eee68c..261
Again, avoid namespace pollution. These paths are purely internal to
libfsimage and its fs-specific modules, so no visible change from the
outside.
Signed-off-by: Ian Jackson
---
v2: New in this version of the series
---
tools/libfsimage/Rules.mk | 2 +-
1 file changed, 1 insertion(+), 1 deleti
This library does not have a stable ABI promise. As far as we know it
is used only by pygrub. Bump its soname to the Xen version (and
intend to change it each time).
Signed-off-by: Ian Jackson
---
v2: New in this version of the series
---
tools/libfsimage/common/Makefile
From: Ian Jackson
This seems to have been simply omitted. Obviously this is needed when
building and not just when installing. Passing only when installing
is ineffective.
Signed-off-by: Ian Jackson
---
tools/pygrub/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
>>> On 04.10.18 at 17:43, wrote:
> This will give us a Xen setting in idle loop. This doesn't have
> practical use except for debugging purpose.
Hmm, that's an acceptable alternative to the panic() variant, but
I'd still prefer that one. Again - let's see if Andrew has an opinion
either way.
Jan
>>> On 04.10.18 at 17:43, wrote:
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 04.10.18 at 17:43, wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -37,6 +37,14 @@ source "arch/Kconfig"
>
> config PV
> def_bool y
> + prompt "PV support"
> + ---help---
> + Interfaces to support PV guests which don't require hardware
> +
>>> On 04.10.18 at 17:43, wrote:
> They will be used by build tests.
And is it difficult for the build tests to set these up themselves?
I don't really like such additions, in particular the neither-PV-nor-
HVM one (which is otherwise completely useless). At the very
least that one should gain a
As a convenient helper function and refactor the code to use it.
No functional change.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c | 17 -
xen/include/asm-x86/hvm/nestedhvm.h | 5 +
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/xen
And make nvmx_handle_vmclear() return the new errno in case the provided
address is the same as vmxon region address.
While at it, correct the return value for not-4KB-aligned case and for
invalid physaddr.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c| 23 +++
On 12/10/18 16:12, Jan Beulich wrote:
On 04.10.18 at 17:43, wrote:
>> This will give us a Xen setting in idle loop. This doesn't have
>> practical use except for debugging purpose.
> Hmm, that's an acceptable alternative to the panic() variant, but
> I'd still prefer that one. Again - let's s
These were found by running nested VMX tests from kvm-unit-tests.
Sergey Dyasli (6):
x86/vvmx: introduce vvmcx_valid()
x86/vvmx: correct vmfail() usage for vmptrld and vmclear
x86/vvmx: add VMX_INSN_VMPTRLD_WITH_VMXON_PTR errno
x86/vvmx: add VMX_INSN_VMCLEAR_WITH_VMXON_PTR errno
x86/vvmx
The size of Xen's virtual vmcs region is 4096 bytes. Correctly report
it to the guest in case when VMCS shadowing is not available instead of
providing H/W value (which is usually smaller).
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c | 8
1 file changed, 8 insertions(+)
And make nvmx_handle_vmptrld() return the new errno in case the provided
address is the same as vmxon region address.
While at it, correct the return value for not-4KB-aligned case.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c| 10 --
xen/include/asm-x86/hvm/vmx/
Currently Xen tries to map bitmaps during emulation of vmptrld and
vmwrite. This is wrong: the guest can store arbitrary values in those
fields.
Make bitmaps mapping happen only during a nested vmentry and only if
the appropriate execution controls are turned on by L1 hypervisor.
Mapping happens o
Calling vmfail_valid() is correct only if vvmcx is valid. Modify
functions to use vmfail() instead which performs the necessary check.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c
Hi Stefano, glad to have you back :D,
this is my setup:
- dom0 is PetaLinux, has 1 vCPU and it's pinned for pCPU0
- there is only one domU and this is my bare-metal app that also
have one vCPU and it's pinned for pCPU1
so yeah, there is only dom0 and bare-metal app on the board.
Ji
On Fri, Oct 12, 2018 at 09:19:45AM -0600, Jan Beulich wrote:
> >>> On 04.10.18 at 17:43, wrote:
> > They will be used by build tests.
>
> And is it difficult for the build tests to set these up themselves?
I specifically said "build tests" but not "CI systems".
It wouldn't be very difficult for
>>> On 09.10.18 at 11:42, wrote:
> A PVH Dom0 might use TSC scaling or other HVM specific TSC
> adjustments, so only short-circuit the TSC setup for a classic PV
> Dom0.
How that?
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -2125,7 +2125,7 @@ void tsc_set_info(struct domain *d,
On Fri, Oct 12, 2018 at 04:12:12PM +0100, Ian Jackson wrote:
> This library does not have a stable ABI promise. As far as we know it
> is used only by pygrub. Bump its soname to the Xen version (and
> intend to change it each time).
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
__
On Fri, Oct 12, 2018 at 04:12:07PM +0100, Ian Jackson wrote:
> From: Ian Jackson
>
> This seems to have been simply omitted. Obviously this is needed when
> building and not just when installing. Passing only when installing
> is ineffective.
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
On Fri, Oct 12, 2018 at 04:12:06PM +0100, Ian Jackson wrote:
> From: Ian Jackson
>
> This command does the link, so it needs LDFLAGS.
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
I think this needs an ack from Elena as well.
> ---
> tools/debugger/gdbsx/Makefile | 2 +-
> 1 file change
On Fri, Oct 12, 2018 at 04:12:10PM +0100, Ian Jackson wrote:
> From: Hans van Kranenburg
>
> libxenstore3.0 in Xen 4.8 had this function. We don't really want to
> bump the ABI version (soname) just for this, since we don't think
> there are actual callers anywhere. But tools complain about the
On Fri, Oct 12, 2018 at 04:12:13PM +0100, Ian Jackson wrote:
> `fsimage' is rather general. And we do not expect this library to be
> very useful out of tree because of its unstable ABI.
>
> So add the word `xen'. This will avoid naming conflicts with anyone
> else's fsimage library.
>
> Signed
On Fri, Oct 12, 2018 at 04:12:04PM +0100, Ian Jackson wrote:
> From: Ian Jackson
>
> This allows the caller to provide some LDFLAGS to the Xen build
> system.
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lis
On Fri, Oct 12, 2018 at 04:12:11PM +0100, Ian Jackson wrote:
> These definitions were not properly protected from unwanted operator
> precedence interactions.
>
> Existing use sites in-tree all use & or |, so this does not change any
> actual behaviour in-tree.
>
> The same seems likely to be tru
On Fri, Oct 12, 2018 at 04:12:15PM +0100, Ian Jackson wrote:
> Again, avoid namespace pollution. These paths are purely internal to
> libfsimage and its fs-specific modules, so no visible change from the
> outside.
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
_
On Fri, Oct 12, 2018 at 04:12:14PM +0100, Ian Jackson wrote:
> This module should be called `libxenfsimage' for the same reasons that
> the C library should.
>
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
Upgrade note is needed.
Wei.
___
Xen-deve
>>> On 12.10.18 at 17:34, wrote:
> On Fri, Oct 12, 2018 at 09:19:45AM -0600, Jan Beulich wrote:
>> >>> On 04.10.18 at 17:43, wrote:
>> > They will be used by build tests.
>>
>> And is it difficult for the build tests to set these up themselves?
>
> I specifically said "build tests" but not "CI
>>> On 09.10.18 at 11:42, wrote:
> No functional change expected.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 09.10.18 at 11:42, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -681,6 +681,17 @@ Flag that makes a dom0 boot in PVHv2 mode.
> Flag that makes a dom0 use shadow paging. Only works when "pvh" is
> enabled.
>
> +> `debug-ioport`
> +
>
First of all, hvm_intsrc_mce was not considered here at all, yet nothing
blocks #MC (other than an already in-progress #MC, but dealing with this
is not the purpose of this patch).
Additionally STI-shadow only blocks maskable interrupts, but not NMI.
Signed-off-by: Jan Beulich
--- a/xen/arch/x8
On Fri, Oct 12, 2018 at 04:28:21PM +0100, Andrew Cooper wrote:
> On 12/10/18 16:12, Jan Beulich wrote:
> On 04.10.18 at 17:43, wrote:
> >> This will give us a Xen setting in idle loop. This doesn't have
> >> practical use except for debugging purpose.
> > Hmm, that's an acceptable alternative
On Mon, Oct 01, 2018 at 07:42:12AM -0600, Jan Beulich wrote:
> The system Intel have handed me for AVX512 emulator work ("Gigabyte
> Technology Co., Ltd. X299 AORUS Gaming 3 Pro/X299 AORUS Gaming 3
> Pro-CF, BIOS F3 12/28/2017") would not come up under Xen - it hung in
> the middle of Dom0 PCI init
Wei Liu writes ("Re: [PATCH 10/12] tools/libfsimage: Add `xen' to .h names and
principal .so name"):
> On Fri, Oct 12, 2018 at 04:12:13PM +0100, Ian Jackson wrote:
> > `fsimage' is rather general. And we do not expect this library to be
> > very useful out of tree because of its unstable ABI.
> >
Hi,
Sorry for the formatting.
On Fri, 12 Oct 2018, 17:36 Milan Boberic, wrote:
> Hi Stefano, glad to have you back :D,
> this is my setup:
> - dom0 is PetaLinux, has 1 vCPU and it's pinned for pCPU0
> - there is only one domU and this is my bare-metal app that also
> have one vC
On 12/10/18 16:58, Jan Beulich wrote:
> First of all, hvm_intsrc_mce was not considered here at all, yet nothing
> blocks #MC (other than an already in-progress #MC, but dealing with this
> is not the purpose of this patch).
I don't believe we've got sufficient infrastructure to fix this
reasonabl
On Wed, Sep 26, 2018 at 02:44:07PM +0100, Paul Durrant wrote:
> ...and change the name to amd_iommu_get_address_from_pte() since the
> address read is not necessarily the address of a next level page table.
> (If the 'next level' field is not 1 - 6 then the address is a page
> address).
>
> The co
> -Original Message-
> From: Woods, Brian [mailto:brian.wo...@amd.com]
> Sent: 12 October 2018 17:59
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Suthikulpanit, Suravee
> ; Woods, Brian
> Subject: Re: [PATCH v2] amd-iommu: use correct constants in
> amd_iommu_get_next_table_fr
On Fri, Oct 12, 2018 at 04:27:55PM +0100, Sergey Dyasli wrote:
> Calling vmfail_valid() is correct only if vvmcx is valid. Modify
> functions to use vmfail() instead which performs the necessary check.
>
> Signed-off-by: Sergey Dyasli
Reviewed-by: Wei Liu
I think the code is a bit convoluted b
On Fri, Oct 12, 2018 at 04:27:54PM +0100, Sergey Dyasli wrote:
> As a convenient helper function and refactor the code to use it.
>
> No functional change.
>
> Signed-off-by: Sergey Dyasli
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@li
On Thu, Sep 27, 2018 at 01:46:01PM +0100, Paul Durrant wrote:
> The levels are absolute numbers such that IOMMU_PAGING_MODE_LEVEL_X
> evaluates to X (for the valid range of 0 - 7) so simply use numbers in
> the code.
>
> No functional change.
>
> NOTE: This patch also adds emacs boilerplate to am
On Fri, Oct 12, 2018 at 04:12:06PM +0100, Ian Jackson wrote:
> From: Ian Jackson
>
> This command does the link, so it needs LDFLAGS.
>
> Signed-off-by: Ian Jackson
Acked-by: Elena Ufimtseva
> ---
> tools/debugger/gdbsx/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
On Fri, Oct 12, 2018 at 09:43:43AM -0600, Jan Beulich wrote:
> >>> On 12.10.18 at 17:34, wrote:
> > On Fri, Oct 12, 2018 at 09:19:45AM -0600, Jan Beulich wrote:
> >> >>> On 04.10.18 at 17:43, wrote:
> >> > They will be used by build tests.
> >>
> >> And is it difficult for the build tests to set
> -Original Message-
> From: Woods, Brian [mailto:brian.wo...@amd.com]
> Sent: 12 October 2018 18:14
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Suthikulpanit, Suravee
> ; Woods, Brian
> Subject: Re: [PATCH] amd-iommu: get rid of pointless
> IOMMU_PAGING_MODE_LEVEL_X definiti
On Fri, 12 Oct 2018, Milan Boberic wrote:
> Hi Stefano, glad to have you back :D,
> this is my setup:
> - dom0 is PetaLinux, has 1 vCPU and it's pinned for pCPU0
> - there is only one domU and this is my bare-metal app that also have
> one vCPU and it's pinned for pCPU1
> so yeah,
Hello,
Here it comes, core-scheduling for Credit2 as well. Well, this time,
it's actually group-scheduling (see below).
git://xenbits.xen.org/people/dariof/xen.git
rel/sched/credit2/group-scheduling-RFCv1
http://xenbits.xen.org/gitweb/?p=people/dariof/xen.git;a=shortlog;h=refs/heads/rel/sched
Instead than just a sequence number, and consistently
with what's shown when the runqueues are created.
Also add some more pretty printing here and there.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_credit2.c |5 +++--
1 file cha
For doing load balancing between runqueues, we check the load of each
runqueue, select the one more "distant" than our own load, and then take
the proper runq lock and attempt vcpu migrations.
If we fail to take such lock, we try again, and the idea was to give up
and bail if, during the checking
Load balancing, when happening, at the end of a "scheduler epoch", can
trigger vcpu migration, which in its turn may call runq_tickle(). If the
cpu where this happens was idle, but we're now going to schedule a vcpu
on it, let's update the runq's idle cpus mask accordingly _before_ doing
load balan
Right now, runqueue organization is the only bit of the scheduler that
use such topology related information. But that may not be true forever,
i.e., there may be other boot parameters which takes the same "core",
"socket", etc, strings as argument.
In fact, this is the case of the credit2_group_s
With group scheduling enabled, if a vcpu of, say, domain A, is already
running on a CPU, the other CPUs of the group can only run vcpus of
that same domain. And in fact, we scan the runqueue and look for one.
But then what can happen is that vcpus of domain A takes turns at
switching between idle/
When chosing which vcpu to run next, on a CPU which is in a group where
other vcpus are running already, only consider vcpus of the same domain
(of those vcpus that are running already!).
This is as easy as, in runq_candidate(), while traversing the runqueue,
skipping the vcpus that do not satisfy
Group scheduling is, for us, when a certain group of CPUs can only
execute the vcpus of one domain, at any given time. What CPUs form the
groups can be defined pretty much arbitrarily, but they're usually build
after the system topology. E.g., core-scheduling is a pretty popular
form of group sched
When chosing which CPU should be poked to go pick up a vcpu from the
runqueue, take group-scheduling into account, if it is enabled.
Basically, we avoid tickling CPUs that, even if they are idle, are part
of coscheduling groups where vcpus of other domains (wrt the one waking
up) are already runni
flight 128614 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128614/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 11 xtf-fep fail REGR. vs. 128523
test-xtf-amd64-amd
On 10/09/2018 05:33 AM, Xin Li wrote:
this #define is unnecessary since XSM_INLINE is redefined in
xsm/dummy.h, it's a risk of build breakage, so remove it.
Signed-off-by: Xin Li
Reviewed-by: Jan Beulich
Acked-by: Daniel De Graaf
___
Xen-devel ma
This run is configured for baseline tests only.
flight 75402 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75402/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 128616 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128616/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
test-amd64-i386-xl
On 10/12/2018 05:12 PM, Ian Jackson wrote:
> From: Hans van Kranenburg
No, this was in the changes that I copied back from Ubuntu, it was
written by Stefan Bader:
>8
Description: Re-introduce fake xs_restrict API call
libxenstore cannot remove an API function without changing its ver
flight 128670 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128670/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bbce001515bbfcad24c216b1c9c25057e8c461e9
baseline version:
ovmf 7177be0bd8d372ef7eaa8
1 - 100 of 105 matches
Mail list logo
