branch xen-unstable
xenbranch xen-unstable
job build-armhf-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu
flight 150515 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150515/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438
Tests which
flight 150464 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150464/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 150432
test-amd64-amd64-xl-qemuu-win7-amd64
On 27/05/2020 18:34, Paul Durrant wrote:
> ... in the save/restore code.
>
> This patch replaces direct mapping of the shared_info_frame (retrieved
> using XEN_DOMCTL_getdomaininfo) with save/load of the domain context
> SHARED_INFO record.
>
> No modifications are made to the definition of the
flight 150510 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150510/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 150438
build-armhf
- 29 maj 2020 o 18:12, Tamas K Lengyel tamas.k.leng...@gmail.com napisał(a):
> On Fri, May 29, 2020 at 8:48 AM Tamas K Lengyel
> wrote:
>>
>> On Fri, May 29, 2020 at 7:51 AM Michał Leszczyński
>> wrote:
>> >
>> > - 29 maj 2020 o 15:15, Jürgen Groß jgr...@suse.com napisał(a):
>> >
>> > >
flight 150505 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 150438
build-amd64
flight 150460 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150460/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 150294
Tests which did not
On 27/05/2020 20:18, Andrew Cooper wrote:
> This series implements Shadow Stack support for Xen to use.
Given that we almost got to agreement, and considering the value of this
feature, I've fixed up most of the remaining comments and committed the
series.
The main area of concern was the
On 29/05/2020 20:35, Andrew Cooper wrote:
>>> +}
>>> +map_pages_to_xen((unsigned long)p, virt_to_mfn(p), 1,
>>> PAGE_HYPERVISOR_SHSTK);
>> As already hinted at in reply to the previous patch, I think this wants
>> to remain _PAGE_NONE when we don't use CET-SS.
> The commit message
On 29/05/2020 19:28, Juergen Gross wrote:
> xen/tools/binfile contains a bash specific command (let). This leads
> to build failures on systems not using bash as /bin/sh.
>
> Replace "let SHIFT=$OPTIND-1" by "SHIFT=$((OPTIND-1))".
>
> Signed-off-by: Juergen Gross
A/T-by and pushed. Thanks for
On 29/05/2020 20:43, Andrew Cooper wrote:
> On 28/05/2020 17:15, Jan Beulich wrote:
>> On 27.05.2020 21:18, Andrew Cooper wrote:
>>> +
>>> +if ( ptr[0] == regs->rip && ptr[1] == regs->cs )
>>> +{
>>> +asm ( "wrssq %[fix], %[stk]"
>>> + : [stk] "=m"
flight 150502 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 150438
build-amd64
On 29/05/2020 14:09, Jan Beulich wrote:
> On 27.05.2020 21:18, Andrew Cooper wrote:
>> With all other plumbing in place, activate shadow stacks when possible. Note
>> that this requires prohibiting the use of PV32. Compatibility can be
>> maintained if necessary via PV-Shim.
> In the revision
On 29/05/2020 13:52, Jan Beulich wrote:
> On 27.05.2020 21:18, Andrew Cooper wrote:
>> See code for details
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Beulich
>> CC: Wei Liu
>> CC: Roger Pau Monné
>>
>> Semi-RFC - I can't actually test this path. Currently attempting to arrange
>>
On 29/05/2020 13:40, Jan Beulich wrote:
> On 27.05.2020 21:18, Andrew Cooper wrote:
>> The SYSCALL/SYSENTER/SYSRET paths need to use {SET,CLR}SSBSY. The IRET to
>> guest paths must not. In the SYSRET path, re-position the mov which loads
>> rip
>> into %rcx so we can use %rcx for CLRSSBSY,
On 29/05/2020 13:23, Jan Beulich wrote:
> On 27.05.2020 21:18, Andrew Cooper wrote:
>> @@ -398,6 +399,19 @@ static void __init _alternative_instructions(bool force)
>> panic("Timed out waiting for alternatives self-NMI to hit\n");
>>
>> set_nmi_callback(saved_nmi_callback);
>> +
>>
On 28/05/2020 17:15, Jan Beulich wrote:
> On 27.05.2020 21:18, Andrew Cooper wrote:
>> @@ -400,6 +400,18 @@ unsigned long get_stack_trace_bottom(unsigned long sp)
>> }
>> }
>>
>> +static unsigned long get_shstk_bottom(unsigned long sp)
>> +{
>> +switch ( get_stack_page(sp) )
>> +{
On 28/05/2020 13:50, Jan Beulich wrote:
> On 27.05.2020 21:18, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -769,6 +769,30 @@ void load_system_tables(void)
>> tss->rsp1 = 0x8600ul;
>> tss->rsp2 = 0x8600ul;
>>
On 28/05/2020 13:33, Jan Beulich wrote:
> On 27.05.2020 21:18, Andrew Cooper wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -365,20 +365,15 @@ static void show_guest_stack(struct vcpu *v, const
>> struct cpu_user_regs *regs)
>> /*
>> * Notes for
Hi,
On 5/26/20 9:41 AM, Jan Beulich wrote:
> On 25.05.2020 17:51, Hans van Kranenburg wrote:
>> This bug report is a follow-up to the thread "Domu windows 2012 crash"
>> on the xen-users list. In there we found out that it is possible to set
>> a value for shadow_memory that is lower than a safe
flight 150498 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150498/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 150438
build-amd64
On 28/05/2020 14:31, Jan Beulich wrote:
> On 28.05.2020 15:22, Andrew Cooper wrote:
>> On 28/05/2020 13:03, Jan Beulich wrote:
>>> On 27.05.2020 21:18, Andrew Cooper wrote:
@@ -940,7 +944,8 @@ autogen_stubs: /* Automatically generated stubs. */
entrypoint 1b
On 29/05/2020 16:51, Anthony PERARD wrote:
> On Fri, May 29, 2020 at 01:59:55PM +0200, Jan Beulich wrote:
>> On 28.05.2020 20:10, Andrew Cooper wrote:
>>> On 28/05/2020 11:25, Jan Beulich wrote:
On 27.05.2020 21:18, Andrew Cooper wrote:
> --- a/xen/scripts/Kconfig.include
> +++
On 29/05/2020 12:59, Jan Beulich wrote:
> On 28.05.2020 20:10, Andrew Cooper wrote:
>> On 28/05/2020 11:25, Jan Beulich wrote:
>>> On 27.05.2020 21:18, Andrew Cooper wrote:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -34,6 +34,10 @@ config ARCH_DEFCONFIG
config
xen/tools/binfile contains a bash specific command (let). This leads
to build failures on systems not using bash as /bin/sh.
Replace "let SHIFT=$OPTIND-1" by "SHIFT=$((OPTIND-1))".
Signed-off-by: Juergen Gross
---
xen/tools/binfile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On 29/05/2020 16:43, Anthony PERARD wrote:
> Commit 534519f0514f ("xen: Have Kconfig check $(CC)'s version")
> introduced the use of CLANG_FLAGS in Kconfig which is used when
> testing for other CFLAGS via $(cc-option ...) but CLANG_FLAGS doesn't
> exist in the Xen build system. (It's a
On Fri, May 29, 2020 at 10:32 AM Ian Jackson wrote:
>
> Andrew Cooper writes ("Re: [PATCH v2 for-4.14] tools/libxl: fix setting
> altp2m param broken by 1e9bc407cf0"):
> > On 29/05/2020 17:22, Tamas K Lengyel wrote:
> > > The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
>
flight 150495 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150495/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 150438
build-amd64
Hi Jan,
On 29/05/2020 16:11, Jan Beulich wrote:
On 29.05.2020 17:05, Julien Grall wrote:
On 29/05/2020 15:47, Ian Jackson wrote:
George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
Which isn’t to say we shouldn’t do it; but it might be nice to also have an
intermediate
> On May 29, 2020, at 4:30 AM, Daniel Kiper wrote:
>
> Hey,
>
> Below you can find my rough idea of the bootloader log format which is
> generic thing but initially will be used for TrenchBoot work. I discussed
> this proposal with Ross and Daniel S. So, the idea went through initial
>
On Thu, May 28, 2020 at 12:32:02PM +0100, George Dunlap wrote:
> On May 27, 2020, at 12:29 PM, Wei Liu wrote:
> > All automation patches:
> >
> > Acked-by: Wei Liu
> >
> > Anthony, can you generate and push the new images? Thanks.
>
> These are checked in now.
>
> BTW it looks like there may
Andrew Cooper writes ("Re: [PATCH v2 for-4.14] tools/libxl: fix setting altp2m
param broken by 1e9bc407cf0"):
> On 29/05/2020 17:22, Tamas K Lengyel wrote:
> > The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
> > boolean. This is incorrect and breaks external-only usecases
On 29/05/2020 17:22, Tamas K Lengyel wrote:
> The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
> boolean. This is incorrect and breaks external-only usecases of altp2m that
> is set with a value of 2.
>
> Signed-off-by: Tamas K Lengyel
Reviewed-by: Andrew Cooper
Sorry
On 22/05/2020 11:07, Jan Beulich wrote:
> On 21.05.2020 18:46, Andrew Cooper wrote:
>> On 05/05/2020 07:16, Jan Beulich wrote:
>>> While the mere updating of ->pv_cr3 and ->root_pgt_changed aren't overly
>>> expensive (but still needed only for the toggle_guest_mode() path), the
>>> effect of the
The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
boolean. This is incorrect and breaks external-only usecases of altp2m that
is set with a value of 2.
Signed-off-by: Tamas K Lengyel
---
v2: just convert bool to unsigned int
---
tools/libxl/libxl_x86.c | 2 +-
1 file
On Fri, May 29, 2020 at 10:15 AM Andrew Cooper
wrote:
>
> On 29/05/2020 17:06, Tamas K Lengyel wrote:
> > The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
> > boolean. This is incorrect and breaks external-only usecases of altp2m that
> > is set with a value of 2.
> >
> >
On 29/05/2020 17:06, Tamas K Lengyel wrote:
> The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
> boolean. This is incorrect and breaks external-only usecases of altp2m that
> is set with a value of 2.
>
> Signed-off-by: Tamas K Lengyel
Urg yes. Sorry.
However, this
> On May 29, 2020, at 12:46 PM, Dario Faggioli wrote:
>
> So,
>
> I felt like providing some additional thoughts about this series, from
> a release point of view (adding Paul).
>
> Timing is *beyond tight* so if this series, entirely or partly, has any
> chance to go in, it would be through
On Fri, May 29, 2020 at 8:48 AM Tamas K Lengyel
wrote:
>
> On Fri, May 29, 2020 at 7:51 AM Michał Leszczyński
> wrote:
> >
> > - 29 maj 2020 o 15:15, Jürgen Groß jgr...@suse.com napisał(a):
> >
> > > On 29.05.20 14:51, Michał Leszczyński wrote:
> > >> - 29 maj 2020 o 14:44, Jürgen Groß
The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
boolean. This is incorrect and breaks external-only usecases of altp2m that
is set with a value of 2.
Signed-off-by: Tamas K Lengyel
---
tools/libxl/libxl_x86.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
Paul Durrant writes ("RE: [PATCH v3] docs: update xenstore-migration.md"):
> > -Original Message-
> > From: Xen-devel On Behalf Of
> > Juergen Gross
> > Sent: 29 May 2020 12:37
> > To: xen-devel@lists.xenproject.org
> > Cc: Juergen Gross ; Stefano Stabellini
> > ; Julien Grall
> > ; Wei
Andrew Cooper writes ("Re: [PATCH 17/20] tools/libx[cl]: Plumb
static_data_done() up into libxl"):
> There are several things going on here.
>
> One is the control flow marker of "We reached the end of the static
> data". A higher level toolstack needs to know this unconditionally,
> which is
Andrew Cooper writes ("Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END
inference for v2 compatibility"):
> On 05/03/2020 16:24, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END
> > inference for v2 compatibility"):
> >> More importantly
On Fri, May 29, 2020 at 01:59:55PM +0200, Jan Beulich wrote:
> On 28.05.2020 20:10, Andrew Cooper wrote:
> > On 28/05/2020 11:25, Jan Beulich wrote:
> >> On 27.05.2020 21:18, Andrew Cooper wrote:
> >>> --- a/xen/scripts/Kconfig.include
> >>> +++ b/xen/scripts/Kconfig.include
> >>> @@ -31,6 +31,10
Juergen Gross writes ("[PATCH] tools: fix Rules.mk library make variables"):
> Both SHDEPS_libxendevicemodel and SHDEPS_libxenhypfs have a bug by
> adding $(SHLIB_xencall) instead of $(SHLIB_libxencall).
>
> The former seems not to have any negative impact, probably because
> it is not used
Andrew Cooper writes ("[PATCH v2 17/17] docs/xl.cfg: Rewrite cpuid= section"):
> This is partly to adjust the description of 'k' and 's' seeing as they have
> changed, but mostly restructuring the information for clarity.
>
> In particular, use indentation to clearly separate the areas discussing
On 28.05.2020 16:40, Roger Pau Monne wrote:
> LLVM linker doesn't support discarding .shstrtab, and complains with:
>
> ld -melf_i386_fbsd -N -T build32.lds -o reloc.lnk reloc.o
> ld: error: discarding .shstrtab section is not allowed
Well, yes, GNU ld is more intelligent and doesn't extend the
Commit 534519f0514f ("xen: Have Kconfig check $(CC)'s version")
introduced the use of CLANG_FLAGS in Kconfig which is used when
testing for other CFLAGS via $(cc-option ...) but CLANG_FLAGS doesn't
exist in the Xen build system. (It's a Linux/Kbuild variable that
haven't been added yet.)
The
flight 150457 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150457/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150420
On Fri, 2020-05-29 at 17:23 +0200, Jürgen Groß wrote:
> On 28.05.20 23:29, Dario Faggioli wrote:
> > In Credit2 CPUs (can) share runqueues, depending on the topology.
> > For
> > instance, with per-socket runqueues (the default) all the CPUs that
> > are
> > part of the same socket share a
On 29/05/2020 16:17, Igor Druzhinin wrote:
> On 29/05/2020 15:34, Jan Beulich wrote:
>> On 29.05.2020 02:35, Igor Druzhinin wrote:
>>> A recalculation NPT fault doesn't always require additional handling
>>> in hvm_hap_nested_page_fault(), moreover in general case if there is no
>>> explicit
On 28.05.20 23:29, Dario Faggioli wrote:
In Credit2 CPUs (can) share runqueues, depending on the topology. For
instance, with per-socket runqueues (the default) all the CPUs that are
part of the same socket share a runqueue.
On platform with a huge number of CPUs per socket, that could be a
On 29.05.2020 17:03, Andrew Cooper wrote:
> On 29/05/2020 14:29, Jan Beulich wrote:
>> On 29.05.2020 14:18, Andrew Cooper wrote:
>>> On 25/05/2020 15:26, Jan Beulich wrote:
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -11474,25
On 29/05/2020 15:34, Jan Beulich wrote:
> On 29.05.2020 02:35, Igor Druzhinin wrote:
>> A recalculation NPT fault doesn't always require additional handling
>> in hvm_hap_nested_page_fault(), moreover in general case if there is no
>> explicit handling done there - the fault is wrongly considered
flight 150488 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150488/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 150438
build-amd64
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug
On 29.05.2020 17:05, Julien Grall wrote:
> On 29/05/2020 15:47, Ian Jackson wrote:
>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an
>>> intermediate solution that works right now, even if
On 28.05.2020 16:40, Roger Pau Monne wrote:
> Clang 10 complains with:
>
> mm.c:1239:10: error: converting the result of '<<' to a boolean always
> evaluates to true
> [-Werror,-Wtautological-constant-compare]
> if ( _PAGE_GNTTAB && (l1e_get_flags(l1e) & _PAGE_GNTTAB) &&
And taking
On 29/05/2020 15:57, Jan Beulich wrote:
> On 28.05.2020 15:07, Andrew Cooper wrote:
>> domain_crash() should always have a message which emitted even in release
> Oh, forgot to say: The wording here looks somewhat strange (and thus
> unclear) to me.
It should read "which is emitted", but this is
On 29/05/2020 14:41, Jan Beulich wrote:
> On 29.05.2020 14:24, Andrew Cooper wrote:
>> On 25/05/2020 15:26, Jan Beulich wrote:
>>> Unlike similarly encoded insns these don't write their memory operands,
>> "write to their".
>>
>>> and hence x86_is_mem_write() should return false for them. However,
Hi Ian,
On 29/05/2020 15:47, Ian Jackson wrote:
George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
Which isn’t to say we shouldn’t do it; but it might be nice to also have an
intermediate solution that works right now, even if it’s not optimal.
I propose the following
On 29/05/2020 15:33, Roger Pau Monné wrote:
> On Fri, May 29, 2020 at 01:35:53AM +0100, Igor Druzhinin wrote:
>> A recalculation NPT fault doesn't always require additional handling
>> in hvm_hap_nested_page_fault(), moreover in general case if there is no
>> explicit handling done there - the
On Fri, 2020-05-29 at 13:46 +0200, Dario Faggioli wrote:
> Basically, if we just consider patches 1 and 4 we will end up, right
> after boot, with a system that has smaller runqueues.
>
Actually, to be fully precise, given how I reorganized the series, it's
not patches 1 and 4, it's patches 1, 3
On 29/05/2020 14:29, Jan Beulich wrote:
> On 29.05.2020 14:18, Andrew Cooper wrote:
>> On 25/05/2020 15:26, Jan Beulich wrote:
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -11474,25 +11474,87 @@ x86_insn_operand_ea(const struct x86_emu
On 29.05.2020 16:47, Ian Jackson wrote:
> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an
>> intermediate solution that works right now, even if it’s not optimal.
>
> I propose the following
On 28.05.2020 15:07, Andrew Cooper wrote:
> domain_crash() should always have a message which emitted even in release
Oh, forgot to say: The wording here looks somewhat strange (and thus
unclear) to me.
> builds, so something more useful than this is presented.
>
> (XEN) domain_crash called
On Fri, 2020-05-29 at 16:54 +0200, Jürgen Groß wrote:
> On 28.05.20 23:29, Dario Faggioli wrote:
> > If we need to know within which pool a particular scheduler
> > is working, we can do that by querying the cpupool pointer
> > of any of the sched_resource-s (i.e., ~ any of the CPUs)
> > assigned
On 28.05.20 23:29, Dario Faggioli wrote:
If we need to know within which pool a particular scheduler
is working, we can do that by querying the cpupool pointer
of any of the sched_resource-s (i.e., ~ any of the CPUs)
assigned to the scheduler itself.
Basically, we pick any sched_resource that
On 28.05.20 23:29, Dario Faggioli wrote:
As it will be useful in later changes. While there, fix
the doc-comment.
No functional change intended.
Signed-off-by: Dario Faggioli
Reviewed-by: Juergen Gross
Juergen
On 28.05.2020 16:40, Roger Pau Monne wrote:
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -20,7 +20,11 @@
>
> #define __weak__attribute__((__weak__))
>
> -#define nocall__attribute__((error("Nonstandard ABI")))
> +#if !defined(__clang__)
> +#
On Fri, May 29, 2020 at 7:51 AM Michał Leszczyński
wrote:
>
> - 29 maj 2020 o 15:15, Jürgen Groß jgr...@suse.com napisał(a):
>
> > On 29.05.20 14:51, Michał Leszczyński wrote:
> >> - 29 maj 2020 o 14:44, Jürgen Groß jgr...@suse.com napisał(a):
> >>
> >>> On 29.05.20 14:30, Michał
On 28.05.20 23:29, Dario Faggioli wrote:
Just move the big if() condition in an inline function.
No functional change intended.
Signed-off-by: Dario Faggioli
Reviewed-by: Juergen Gross
Juergen
George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."):
> Which isn’t to say we shouldn’t do it; but it might be nice to also have an
> intermediate solution that works right now, even if it’s not optimal.
I propose the following behaviour by updste-grub:
1. Look for an ELF
On 28.05.2020 15:07, Andrew Cooper wrote:
> domain_crash() should always have a message which emitted even in release
> builds, so something more useful than this is presented.
>
> (XEN) domain_crash called from io.c:171
> (XEN) domain_crash called from io.c:171
> (XEN) domain_crash called
On Fri, May 29, 2020 at 02:37:24PM +0100, Julien Grall wrote:
> Hi,
>
> On 29/05/2020 14:26, Roger Pau Monné wrote:
> > TBH I would just remove the error message on Arm from the current
> > hypercall, I don't think it's useful.
> The message is part of the helpers get_page_from_gva() which is
On 29.05.2020 02:35, Igor Druzhinin wrote:
> A recalculation NPT fault doesn't always require additional handling
> in hvm_hap_nested_page_fault(), moreover in general case if there is no
> explicit handling done there - the fault is wrongly considered fatal.
>
> Instead of trying to be
On Fri, May 29, 2020 at 01:35:53AM +0100, Igor Druzhinin wrote:
> A recalculation NPT fault doesn't always require additional handling
> in hvm_hap_nested_page_fault(), moreover in general case if there is no
> explicit handling done there - the fault is wrongly considered fatal.
>
> Instead of
On 25/05/2020 15:30, Jan Beulich wrote:
> Note that FPU selector handling as well as MXCSR mask saving for now
> does not honor differences between host and guest visible featuresets.
>
> While for Intel operation of the insns with CR4.OSFXSR=0 is
> implementation dependent, use the easiest
> On 29 May 2020, at 15:15, Julien Grall wrote:
>
>
>
> On 29/05/2020 15:02, Bertrand Marquis wrote:
>>> On 29 May 2020, at 10:43, Julien Grall wrote:
>>>
>>> Hi Bertrand,
>>>
>>> On 29/05/2020 09:13, Bertrand Marquis wrote:
Hi Julien,
> On 28 May 2020, at 19:54, Julien Grall
On 29/05/2020 15:02, Bertrand Marquis wrote:
On 29 May 2020, at 10:43, Julien Grall wrote:
Hi Bertrand,
On 29/05/2020 09:13, Bertrand Marquis wrote:
Hi Julien,
On 28 May 2020, at 19:54, Julien Grall wrote:
Hi Bertrand,
Thank you for the patch.
On 28/05/2020 16:25, Bertrand Marquis
On 29.05.2020 16:08, Andrew Cooper wrote:
> On 25/05/2020 15:29, Jan Beulich wrote:
>> To avoid introducing another boolean into emulator state, the
>> rex_prefix field gets (ab)used to convey the real/VM86 vs protected mode
>> info (affecting structure layout, albeit not size) to x86_emul_blk().
On 25/05/2020 15:29, Jan Beulich wrote:
> While the Intel SDM claims that FRSTOR itself may raise #MF upon
> completion, this was confirmed by Intel to be a doc error which will be
> corrected in due course; behavior is like FLDENV, and like old hard copy
> manuals describe it.
>
> Re-arrange a
On 25/05/2020 15:29, Jan Beulich wrote:
> To avoid introducing another boolean into emulator state, the
> rex_prefix field gets (ab)used to convey the real/VM86 vs protected mode
> info (affecting structure layout, albeit not size) to x86_emul_blk().
>
> Signed-off-by: Jan Beulich
Acked-by:
> On 29 May 2020, at 10:43, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 29/05/2020 09:13, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 28 May 2020, at 19:54, Julien Grall wrote:
>>>
>>> Hi Bertrand,
>>>
>>> Thank you for the patch.
>>>
>>> On 28/05/2020 16:25, Bertrand Marquis wrote:
On 29.05.2020 15:55, Andrew Cooper wrote:
> On 25/05/2020 15:28, Jan Beulich wrote:
>> Introduce a new blk() hook, paralleling the rmw() one in a certain way,
>> but being intended for larger data sizes, and hence its HVM intermediate
>> handling function doesn't fall back to splitting the
On 25/05/2020 15:28, Jan Beulich wrote:
> Introduce a new blk() hook, paralleling the rmw() one in a certain way,
> but being intended for larger data sizes, and hence its HVM intermediate
> handling function doesn't fall back to splitting the operation if the
> requested virtual address can't be
> On 29 May 2020, at 10:27, Roger Pau Monné wrote:
>
> On Fri, May 29, 2020 at 09:18:42AM +, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 29 May 2020, at 09:45, Jan Beulich wrote:
>>>
>>> On 29.05.2020 10:13, Bertrand Marquis wrote:
> On 28 May 2020, at 19:54, Julien Grall wrote:
The default value '/' for DESTDIR is unusual, but does probably not hurt.
Fixes commit f2b40dababedcd8355bf3e85d00baf17f9827131
Fixes commit 8e986e5a61efeca92b9b268e77957d45d8316ee4
Signed-off-by: Olaf Hering
---
INSTALL | 7 ---
1 file changed, 7 deletions(-)
diff --git a/INSTALL
- 29 maj 2020 o 15:15, Jürgen Groß jgr...@suse.com napisał(a):
> On 29.05.20 14:51, Michał Leszczyński wrote:
>> - 29 maj 2020 o 14:44, Jürgen Groß jgr...@suse.com napisał(a):
>>
>>> On 29.05.20 14:30, Michał Leszczyński wrote:
Hello,
I'm running DRAKVUF on Dell Inc.
On 29.05.2020 14:24, Andrew Cooper wrote:
> On 25/05/2020 15:26, Jan Beulich wrote:
>> Unlike similarly encoded insns these don't write their memory operands,
>
> "write to their".
>
>> and hence x86_is_mem_write() should return false for them. However,
>> rather than adding special logic there,
Hi,
On 29/05/2020 14:26, Roger Pau Monné wrote:
TBH I would just remove the error message on Arm from the current
hypercall, I don't think it's useful.
The message is part of the helpers get_page_from_gva() which is also
used by copy_{to, from}_guest. While it may not be useful in the context
flight 150479 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150479/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 150438
build-amd64
On 29.05.2020 14:18, Andrew Cooper wrote:
> On 25/05/2020 15:26, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -11474,25 +11474,87 @@ x86_insn_operand_ea(const struct x86_emu
>> return state->ea.mem.off;
>> }
>>
>>
On Fri, May 29, 2020 at 08:32:51AM +, Bertrand Marquis wrote:
> Hi Jan
>
> > On 29 May 2020, at 08:35, Jan Beulich wrote:
> >
> > On 28.05.2020 20:54, Julien Grall wrote:
> >> On 28/05/2020 16:25, Bertrand Marquis wrote:
> >>> At the moment on Arm, a Linux guest running with KTPI enabled
Paul Durrant writes ("RE: [OSSTEST PATCH v2 00/49] Switch to Debian buster (=
Debian stable)"):
> I assume we can revert if things go badly wrong and being able to commission
> more machines would seem to be quite beneficial at this
> stage.
Thanks for your opinion.
It would be possible to
On 29.05.20 14:51, Michał Leszczyński wrote:
- 29 maj 2020 o 14:44, Jürgen Groß jgr...@suse.com napisał(a):
On 29.05.20 14:30, Michał Leszczyński wrote:
Hello,
I'm running DRAKVUF on Dell Inc. PowerEdge R640/08HT8T server with Intel(R)
Xeon(R) Gold 6132 CPU @ 2.60GHz CPU.
When upgrading
On Fri, May 29, 2020 at 11:59:40AM +0100, Julien Grall wrote:
> Hi Jan,
>
> On 29/05/2020 08:35, Jan Beulich wrote:
> > On 28.05.2020 20:54, Julien Grall wrote:
> > > On 28/05/2020 16:25, Bertrand Marquis wrote:
> > > > At the moment on Arm, a Linux guest running with KTPI enabled will
> > > >
On 27.05.2020 21:18, Andrew Cooper wrote:
> With all other plumbing in place, activate shadow stacks when possible. Note
> that this requires prohibiting the use of PV32. Compatibility can be
> maintained if necessary via PV-Shim.
In the revision log you say "Discuss CET-SS disabling PV32", and
flight 150462 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150462/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
1 - 100 of 240 matches
Mail list logo
