flight 143061 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143061/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm broken
test-amd64-amd64-xl-qemut-stub
flight 143060 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143060/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-qem
On 10/22/2019 10:42 PM, David Hildenbrand wrote:
> Our onlining/offlining code is unnecessarily complicated. Only memory
> blocks added during boot can have holes. Hotplugged memory never has
> holes. That memory is already online.
Why hot plugged memory at runtime cannot have holes (e.g a semi b
Remove unused (#ifdef-ed out) code. Reviving it in its current shape
won't fly because:
- SetVirtualAddressMap() needs to be called with 1:1 mapping, which
isn't the case at this time
- it uses directmap, which may go away soon
- it uses directmap, which is mapped with NX, breaking EfiRuntime
Do not require switching page tables to access (static) information in
the runtime services table itself, use directmap for this. This allows
exiting early from XEN_EFI_query_capsule_capabilities,
XEN_EFI_update_capsule and XEN_EFI_query_variable_info (in case of not
supported call) without all the
Some UEFI implementations are not happy about lack of
SetVirtualAddressMap() call. Likely abuse the address map change
notification to do things beyond the necessary ConvertPointer() calls.
Specifically, wihtout the SetVirtualAddressMap() call, some access
EfiBootServices{Code,Data}, or even totall
Workaround buggy UEFI accessing boot services memory after ExitBootServices().
Patches discussed here:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00701.html
In addition to the tests below, I've tested kexec on xen.efi with this option
enabled and it (still) works.
Test result
flight 143057 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143057/
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. 143006
test-amd64-amd64-xl
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, October 23, 2019 10:00 PM
>
> On 11.10.2019 17:33, Roger Pau Monné wrote:
> > On Fri, Oct 11, 2019 at 04:02:53PM +0100, Andrew Cooper wrote:
> >> The virtual address of the base of the IOMMU's regsters is not useful for
> >> diagno
flight 143074 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143074/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 143068 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143068/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
examine-huxelrebe02 hosts-allocate starved n/a
examine-rochester12 hosts-allocate
On 23.10.19 21:39, Dan Williams wrote:
> On Wed, Oct 23, 2019 at 10:28 AM David Hildenbrand wrote:
>>
I dislike this for three reasons
a) It does not protect against any races, really, it does not improve
things.
b) We do have the exact same problem with pfn_to_online_pag
On 2019-10-16 04:06, Daniel Kiper wrote:
> On Wed, Oct 09, 2019 at 12:53:55PM +0200, Daniel Kiper wrote:
>> Hi,
>>
>> Due to very limited space in the setup_header this patch series introduces
>> new
>> kernel_info struct which will be used to convey information from the kernel
>> to
>> the bootl
Hello xen-devel,
https://paste.debian.net/plain/1109374
shows my traces from a healthy CentOS 8, xen-4.12.1 dom0 when trying
to launch a pv install of the newly released ub1910. The source is a
block-attached ISO and the kernel/ramdisk was copied off locally.
Iso is named, eoan-live-server-amd64
On Wed, Oct 23, 2019 at 10:28 AM David Hildenbrand wrote:
>
> >> I dislike this for three reasons
> >>
> >> a) It does not protect against any races, really, it does not improve
> >> things.
> >> b) We do have the exact same problem with pfn_to_online_page(). As long as
> >> we
> >>don't hol
flight 143059 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143059/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501
Tests which did
On Wed, Oct 23, 2019 at 11:48:41AM +0300, K. Kahurani wrote:
> This piece of code is redundant and results in a garbage error
> message on systems that do not have a default python executable.
>
> Signed-off-by: K. Kahurani
> ---
> tools/configure | 4 +---
> 1 file changed, 1 insertion(+), 3 de
El mar, 22-10-2019 a las 11:35 +0200, Philippe Mathieu-Daudé escribió:
> On 10/22/19 10:44 AM, Esteban Bosse wrote:
> > El vie, 18-10-2019 a las 15:47 +0200, Philippe Mathieu-Daudé
> > escribió:
> > > From: Hervé Poussineau
> > >
> > > Add ISA irqs as piix4 gpio in, and CPU interrupt request as p
El mar, 22-10-2019 a las 10:42 +0100, Peter Maydell escribió:
> On Tue, 22 Oct 2019 at 09:52, Esteban Bosse
> wrote:
> > El vie, 18-10-2019 a las 15:47 +0200, Philippe Mathieu-Daudé
> > escribió:
> > > +static void piix4_request_i8259_irq(void *opaque, int irq, int
> > > level)
> > > +{
> > > +
flight 143069 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143069/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>> I dislike this for three reasons
>>
>> a) It does not protect against any races, really, it does not improve things.
>> b) We do have the exact same problem with pfn_to_online_page(). As long as we
>>don't hold the memory hotplug lock, memory can get offlined and remove
>> any time. Racy.
>
Sources of *FLAGS for 32bit build:
- Config.mk
- config/x86_32.mk
- deleted build32.mk
---
xen/arch/x86/boot/Makefile | 72 +---
xen/arch/x86/boot/build32.mk | 40
2 files changed, 58 insertions(+), 54 deletions(-)
delete mode 100
- *FLAGS
- fix path to Kconfig
- List objects to build
- generate include/xen/compile.h
- make prepare phase
- changes to clean
- remove build of kernel.version
---
xen/Makefile | 263 ---
1 file changed, 143 insertions(+), 120 deletions(-)
diff --
---
xen/include/Makefile | 125 ---
1 file changed, 82 insertions(+), 43 deletions(-)
diff --git a/xen/include/Makefile b/xen/include/Makefile
index c3e0283d347f..56eb9b7f4540 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -1,5 +1,3 @@
-inc
archprepare target
make asm-offsets.h
make asm-macros.[ih]
---
xen/Kbuild| 10
xen/arch/x86/Makefile | 54 +--
2 files changed, 37 insertions(+), 27 deletions(-)
create mode 100644 xen/Kbuild
diff --git a/xen/Kbuild b/xen/Kbuild
new fi
---
xen/tools/Makefile | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/xen/tools/Makefile b/xen/tools/Makefile
index e940939d61f4..b43f62592019 100644
--- a/xen/tools/Makefile
+++ b/xen/tools/Makefile
@@ -1,13 +1,2 @@
-
-include $(XEN_ROOT)/Config.mk
-
-.PHONY:
arch/*/Makefile will be included by the root makefile, its job will
mosty be to generate the *FLAGS for this arch.
arch/*/Kbuild will be used by recursive make, to build *.o and
others.
---
xen/arch/x86/Kbuild | 153 ++
xen/arch/x86/Makefile | 148
Kbuild uses obj-y=subdir/ instead of subdir-y=subdir
Adding CFLAGS in a specific subdirectory is done via ccflags-y instead
of CFLAGS.
Done with sed:
sed -i -r 's#^subdir-(.*)#obj-\1/#; s#^CFLAGS #ccflags-y #' **/*/Makefile
---
xen/arch/arm/Makefile| 14 +++---
xen/arc
Makefile.host is now in xen/scripts
Makefile.kconfig isn't needed anymore.
---
xen/tools/kconfig/Makefile.host| 164 -
xen/tools/kconfig/Makefile.kconfig | 126 --
2 files changed, 290 deletions(-)
delete mode 100644 xen/tools/kconfig/Makefile.h
Edit a lot of it out, mostly CFLAGS, build of modules.
Edit in xenversion.
---
xen/Makefile | 1249 --
1 file changed, 1001 insertions(+), 248 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index b1b60e679082..90645668957c 100644
--- a/xen/Ma
---
xen/arch/x86/Makefile | 65 +++
1 file changed, 65 insertions(+)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 49b7eb9fd116..41486c512f10 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -1,3 +1,68 @@
+# select defcon
Rewrite the rules to build the different level of guest page walk so
the work and use Kbuild functions.
Signed-off-by: Anthony PERARD
---
xen/arch/x86/mm/Makefile| 14 +++---
xen/arch/x86/mm/hap/Makefile| 14 +++---
xen/arch/x86/mm/shadow/Makefile | 14 +++---
Use existing command line of objcopy and ld instead of writing new one
and simply edit the flags.
`targets' is to let know kbuild that other files beside the one
declared in obj-bin-y will be built.
Signed-off-by: Anthony PERARD
---
xen/common/libelf/Makefile | 13 +
1 file changed,
UNTESTED
---
xen/common/libfdt/Makefile | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
index 9ea5c696d52a..a233d82b15ee 100644
--- a/xen/common/libfdt/Makefile
+++ b/xen/common/libfdt/Makefile
@@ -1,14 +1,1
Define __OBJECT_FILE__ and __OBJECT_LABEL__ as it is done in
arch/x86/Rules.mk.
Those defines would also be created when doing an ARM build, when
Kbuild will be used to build xen.
Signed-off-by: Anthony PERARD
---
xen/scripts/Makefile.lib | 26 +-
1 file changed, 9 inser
On Wed, Oct 23, 2019 at 12:26 AM David Hildenbrand wrote:
>
> On 22.10.19 23:54, Dan Williams wrote:
> > Hi David,
> >
> > Thanks for tackling this!
>
> Thanks for having a look :)
>
> [...]
>
>
> >> I am probably a little bit too careful (but I don't want to break things).
> >> In most places (be
flight 143054 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143054/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 53b1dd1036df3839d46bb150f7a8b2037390093a
baseline version:
ovmf 46bb81200742fabfe5c56
On 23/10/2019 17:11, Oleksandr wrote:
On 16.10.19 18:04, Julien Grall wrote:
Hi,
Below is example from linux kernel sources:
linux/sound/ppc/awacs.c:741: if (of_machine_is_compatible("PowerBook3,1")
linux/sound/ppc/awacs.c:742: ||
of_machine_is_compatible("PowerBook3,2")) {
linux/
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-v1
Hi,
I have work toward building Xen (the hypervisor) with Linux's build system,
Kbuild.
The main reason for that is to be able to have out-of-tree build. It's annoy
SPECIAL_DATA_SECTIONS is put in Kbuild.include so it can be use in
kbuild makefiles.
Signed-off-by: Anthony PERARD
---
xen/scripts/Kbuild.include | 10 ++
xen/scripts/Makefile.build | 24
xen/scripts/Makefile.lib | 7 +++
3 files changed, 41 insertions(+)
The comment could have been removed with
18cd4997d26b9df95dda87503e41c823279a07a0.
Signed-off-by: Anthony PERARD
---
xen/arch/x86/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 2443fd2cc5bd..af6c83dfbae6 100644
--- a/xen/arch/x86/M
Current description of the file by `file`:
common/Kconfig: Non-ISO extended-ASCII text
Change that byte to an ascii quote so the file can become properly
encoded, and all ASCII.
Signed-off-by: Anthony PERARD
---
xen/common/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Kbuild includes linux/compiler_types.h into the CFLAGS list, but Xen
don't need that.
Signed-off-by: Anthony PERARD
---
xen/scripts/Makefile.lib | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/scripts/Makefile.lib b/xen/scripts/Makefile.lib
index 41c50f9461e5..b746199b7f6b 100644
--- a/xe
As it is done currently in Rules.mk.
Signed-off-by: Anthony PERARD
---
xen/scripts/Makefile.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/scripts/Makefile.build b/xen/scripts/Makefile.build
index 2f66ed388d1c..dd972d5b5edb 100644
--- a/xen/scripts/Makefile.build
+
As it is done in the same rule in Rules.mk.
Signed-off-by: Anthony PERARD
---
xen/scripts/Makefile.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/scripts/Makefile.build b/xen/scripts/Makefile.build
index 68b504c9bdc5..c8ef52220a61 100644
--- a/xen/scripts/Makefile.
This functions will be use later to generate asm-offsets.h.
Signed-off-by: Anthony PERARD
---
xen/scripts/Makefile.lib | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/xen/scripts/Makefile.lib b/xen/scripts/Makefile.lib
index e022f053494e..19641e836dc3 100
This patch import part of Kbuild, the build system from Linux v5.3,
4d856f72c10ecb060868ed10ff1b1453943fc6c8.
File imported:
scripts/{Makefile.*,Kbuild.include} -> xen/scripts/
scripts/basic -> xen/scripts/basic
scripts/mkmakefile -> xen/scripts/Makefile
but without:
- Extra warning (c
On Wed, Oct 23, 2019 at 06:10:55PM +0200, Jan Beulich wrote:
> On 23.10.2019 17:36, Marek Marczykowski-Górecki wrote:
> > No, it still setup 1:1 page tables for the runtime calls, exactly as it
> > was before.
>
> But the "physical" is no longer correct.
Ok, I'll add it to the other patch (as it
On 10/23/19 2:58 PM, Andrew Cooper wrote:
From: Ross Lagerwall
The binary diffing algorithm used by xen-livepatch depends on having unique
symbols.
Signed-off-by: Ross Lagerwall
Presumably this should be "livepatch-build" or "livepatch-build-tools"
rather than "xen-livepatch".
--
Ross Lag
On 23.10.19 18:25, Kees Cook wrote:
> On Wed, Oct 23, 2019 at 10:20:14AM +0200, David Hildenbrand wrote:
>> On 22.10.19 19:12, David Hildenbrand wrote:
>>> Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
>>> change that.
>>>
>>> Let's make sure that the logic in the function won
On Wed, Oct 23, 2019 at 10:20:14AM +0200, David Hildenbrand wrote:
> On 22.10.19 19:12, David Hildenbrand wrote:
> > Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
> > change that.
> >
> > Let's make sure that the logic in the function won't change. Once we no
> > longer set t
Both are now potentially asynchronous; pass in 'nil' to retain
synchronous behavior.
Signed-off-by: George Dunlap
---
Release justification: This is a bug fix for 4.13.
CC: Nick Rosbrook
CC: Juergen Gross
---
tools/golang/xenlight/xenlight.go | 4 ++--
1 file changed, 2 insertions(+), 2 delet
On October 23, 2019 10:46:37 AM EDT, "Jürgen Groß" wrote:
>On 23.10.19 15:58, Andrew Cooper wrote:
>> From: Ross Lagerwall
>>
>> The binary diffing algorithm used by xen-livepatch depends on having
>unique
>> symbols.
>>
>> Signed-off-by: Ross Lagerwall
>>
>> The livepatch loading algorithm u
On 23.10.2019 18:07, Marek Marczykowski-Górecki wrote:
> On Wed, Oct 23, 2019 at 05:37:33PM +0200, Jan Beulich wrote:
>> On 13.10.2019 00:11, Marek Marczykowski-Górecki wrote:
>>> @@ -1094,6 +1100,26 @@ static void __init efi_exit_boot(EFI_HANDLE
>>> ImageHandle, EFI_SYSTEM_TABLE *Syste
>>>
On 23.10.2019 17:36, Marek Marczykowski-Górecki wrote:
> On Wed, Oct 23, 2019 at 05:15:42PM +0200, Jan Beulich wrote:
>> On 13.10.2019 00:11, Marek Marczykowski-Górecki wrote:
>>> @@ -1099,9 +1096,6 @@ static void __init efi_exit_boot(EFI_HANDLE
>>> ImageHandle, EFI_SYSTEM_TABLE *Syste
>>>
>>>
On 16.10.19 18:04, Julien Grall wrote:
Hi,
Hi Julien
just my 2 cents)
Below is example from linux kernel sources:
linux/sound/ppc/awacs.c:741: if
(of_machine_is_compatible("PowerBook3,1")
linux/sound/ppc/awacs.c:742: ||
of_machine_is_compatible("PowerBook3,2")) {
linux/soun
On Wed, Oct 23, 2019 at 05:37:33PM +0200, Jan Beulich wrote:
> On 13.10.2019 00:11, Marek Marczykowski-Górecki wrote:
> > Some UEFI implementations are not happy about running in 1:1 addressing,
> > but really virtual address space.
>
> I have to admit that I find this misleading. There's no true
Anthony PERARD writes ("Re: [XEN PATCH for-4.13 v7 11/11] libxl: On ARM, reject
future new passthrough modes too"):
> On Wed, Oct 23, 2019 at 02:00:13PM +0100, Ian Jackson wrote:
> > -if (c_info->passthrough == LIBXL_PASSTHROUGH_SYNC_PT) {
> > +switch (c_info->passthrough) {
> > +case
On Wed, Oct 23, 2019 at 02:00:13PM +0100, Ian Jackson wrote:
> This is most pleasantly done by also changing the if to a switch.
>
> Suggested-by: Julien Grall
> CC: Julien Grall
> CC: Stefano Stabellini
> Signed-off-by: Ian Jackson
>
> ---
> v7: New patch in this version of the series.
> ---
On Wed, Oct 23, 2019 at 05:15:42PM +0200, Jan Beulich wrote:
> On 13.10.2019 00:11, Marek Marczykowski-Górecki wrote:
> > @@ -1099,9 +1096,6 @@ static void __init efi_exit_boot(EFI_HANDLE
> > ImageHandle, EFI_SYSTEM_TABLE *Syste
> >
> > /* Adjust pointers into EFI. */
> > efi_ct = (vo
On 13.10.2019 00:11, Marek Marczykowski-Górecki wrote:
> Some UEFI implementations are not happy about running in 1:1 addressing,
> but really virtual address space.
I have to admit that I find this misleading. There's no true "physical
mode" on x86-64 anyway. What I assume happens is that people
On 13.10.2019 00:11, Marek Marczykowski-Górecki wrote:
> @@ -1591,10 +1576,6 @@ void __init efi_init_memory(void)
> return;
> }
>
> -#ifdef USE_SET_VIRTUAL_ADDRESS_MAP
> -efi_rs->SetVirtualAddressMap(efi_memmap_size, efi_mdesc_size,
> - mdesc_ver
Julien Grall writes ("Re: [OSSTEST PATCH 2/2] make-flight: Drop arm64 with
Linux before 4.10"):
> On 23/10/2019 16:01, Ian Jackson wrote:
> > The driver for the laxtons' network cards is not in 4.4 (and that's
> > quite old). Our ThunderX's may even require something more recent but
> > we will c
On 23.10.19 17:02, Jan Beulich wrote:
__2M_rwdata_end marks the first byte after the Xen image, not its last
byte. Subtract 1 to obtain the upper bound to compare against. (Note
that instead switching from <= to < is less desirable, as in principle
__pa() might return rubbish for addresses outsid
On 23/10/2019 16:02, Jan Beulich wrote:
> __2M_rwdata_end marks the first byte after the Xen image, not its last
> byte. Subtract 1 to obtain the upper bound to compare against. (Note
> that instead switching from <= to < is less desirable, as in principle
> __pa() might return rubbish for addresse
On 13.10.2019 00:11, Marek Marczykowski-Górecki wrote:
> @@ -1099,9 +1096,6 @@ static void __init efi_exit_boot(EFI_HANDLE
> ImageHandle, EFI_SYSTEM_TABLE *Syste
>
> /* Adjust pointers into EFI. */
> efi_ct = (void *)efi_ct + DIRECTMAP_VIRT_START;
> -#ifdef USE_SET_VIRTUAL_ADDRESS_MAP
Hi Ian,
On 23/10/2019 16:01, Ian Jackson wrote:
The driver for the laxtons' network cards is not in 4.4 (and that's
quite old). Our ThunderX's may even require something more recent but
we will cross that bridge when we see it.
Effect is to drop the following jobs:
linux-4.1 *arm64*
lin
flight 143050 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143050/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 142915
test-amd64-amd64-
The driver for the laxtons' network cards is not in 4.4 (and that's
quite old). Our ThunderX's may even require something more recent but
we will cross that bridge when we see it.
Effect is to drop the following jobs:
linux-4.1 *arm64*
linux-4.4 *arm64*
linux-4.9 *arm64*
(Checked by eyeb
__2M_rwdata_end marks the first byte after the Xen image, not its last
byte. Subtract 1 to obtain the upper bound to compare against. (Note
that instead switching from <= to < is less desirable, as in principle
__pa() might return rubbish for addresses outside of the Xen image.)
Since the & needs
Now we have two lists of things not supported on ARM: one of branches
where that's inherent in the branch somehow, and one for those where
the kernel is simply too old. The latter are going to differ between
armhf and arm64.
No functional change.
(Verified with standalone-generate-dump-flight-run
On 23.10.19 15:58, Andrew Cooper wrote:
The include of asm/cpuid.h in spec_ctrl.c was an artefact of an older version
of c/s 3860d5534df, and is not used in its current incarnation.
Fix a typo in a comment.
Signed-off-by: Andrew Cooper
Release-acked-by: Juergen Gross
Juergen
On 23.10.19 15:58, Andrew Cooper wrote:
evaluate_nospec() is incredibly fragile, and this is one giant bodge.
To correctly protect jumps, the generated code needs to be of the form:
cmp/test
jcc 1f
lfence
...
1: lfence
...
Critically, the lfence must be at the head
On 23.10.19 15:58, Andrew Cooper wrote:
l1tf-barrier is an inappropriate name, and came about because of restrictions
on could be discussed publicly when the patches were proposed.
In practice, it is for general Spectre v1 mitigations, and is necessary in all
cases. An adversary which can contr
On 23.10.19 15:58, Andrew Cooper wrote:
From: Ross Lagerwall
The binary diffing algorithm used by xen-livepatch depends on having unique
symbols.
Signed-off-by: Ross Lagerwall
The livepatch loading algorithm used by Xen resolves relocations by symbol
name, and thus also depends on having uni
On 23.10.19 15:58, Andrew Cooper wrote:
Just as with CONFIG_SPECULATIVE_HARDEN_ARRAY, branch hardening should be
configurable at compile time.
The previous CONFIG_HVM was a consequence of what could be discussed publicly
at the time the patches were submitted, and wasn't actually correct. Later
On 16.10.2019 12:53, Julien Grall wrote:
> virt_to_maddr() is using the hardware page-table walk instructions to
> translate a virtual address to physical address. The function should
> only be called on virtual address mapped.
>
> _end points past the end of Xen binary and may not be mapped when
On Wed, Oct 23, 2019 at 04:17:11PM +0200, Jan Beulich wrote:
> On 23.10.2019 15:56, Roger Pau Monne wrote:
> > If Xen detects the TSC is unreliable it will set a rendezvous helper
> > that tries to synchronize the different CPUs TSC value by propagating
> > the one from CPU#0 and writing it into th
On 23.10.19 16:17, Jan Beulich wrote:
On 23.10.2019 15:56, Roger Pau Monne wrote:
If Xen detects the TSC is unreliable it will set a rendezvous helper
that tries to synchronize the different CPUs TSC value by propagating
the one from CPU#0 and writing it into the IA32_TSC MSR on each CPU.
When
On Wed, Oct 23, 2019 at 02:00:12PM +0100, Ian Jackson wrote:
> LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
> version of this code) is doing double duty. We actually need all of
> the following to be specifiable:
> * "default": enable PT iff we have devices to
> pass th
On 23.10.2019 15:56, Roger Pau Monne wrote:
> If Xen detects the TSC is unreliable it will set a rendezvous helper
> that tries to synchronize the different CPUs TSC value by propagating
> the one from CPU#0 and writing it into the IA32_TSC MSR on each CPU.
>
> When the system has a single thread
On 10/23/19 2:59 PM, Juergen Gross wrote:
> Since commit 8d3c326f6756d1 ("xen: let vcpu_create() select processor")
> the initial processor for all pv-shim vcpus will be 0, as no other cpus
> are online when the vcpus are created. Before that commit the vcpus
> would have processors set not being o
On 23.10.2019 10:57, Roger Pau Monne wrote:
> If a HVM/PVH guest writes to MSR_IA32_TSC{_ADJUST} and thus changes
> the value of the time stamp counter the vcpu time info must also be
> updated, or the time calculated by the guest using the Xen PV clock
> interface will be skewed.
>
> Update the v
On 23.10.2019 15:58, Andrew Cooper wrote:
> The include of asm/cpuid.h in spec_ctrl.c was an artefact of an older version
> of c/s 3860d5534df, and is not used in its current incarnation.
>
> Fix a typo in a comment.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 11.10.2019 17:33, Roger Pau Monné wrote:
> On Fri, Oct 11, 2019 at 04:02:53PM +0100, Andrew Cooper wrote:
>> The virtual address of the base of the IOMMU's regsters is not useful for
>> diagnostic purposes, and is quite voluminous. The PCI coordinates is by far
>> the most useful piece of iden
Since commit 8d3c326f6756d1 ("xen: let vcpu_create() select processor")
the initial processor for all pv-shim vcpus will be 0, as no other cpus
are online when the vcpus are created. Before that commit the vcpus
would have processors set not being online yet, which worked just by
chance.
When the
system.h isn't an appropriate place to live, now that asm/nospec.h exists.
This should arguably have been part of c/s db591d6e76e
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Juergen Gross
This is probably post-4.13 content
---
Just as with CONFIG_SPECULATIVE_HARDEN_ARRAY, branch hardening should be
configurable at compile time.
The previous CONFIG_HVM was a consequence of what could be discussed publicly
at the time the patches were submitted, and wasn't actually correct. Later
patches will make further corrections.
S
evaluate_nospec() is incredibly fragile, and this is one giant bodge.
To correctly protect jumps, the generated code needs to be of the form:
cmp/test
jcc 1f
lfence
...
1: lfence
...
Critically, the lfence must be at the head of both basic blocks, later in the
instruction s
This resolves an oustanding blocker for 4.13, fixing both the code generation
for evaulate_nospec(), and making the resulting hypervisor able to be
livepatched.
Andrew Cooper (6):
x86/nospec: Two trivial fixes
xen/nospec: Use always_inline to fix code gen for evaluate_nospec
xen/nospec: Intr
From: Ross Lagerwall
The binary diffing algorithm used by xen-livepatch depends on having unique
symbols.
Signed-off-by: Ross Lagerwall
The livepatch loading algorithm used by Xen resolves relocations by symbol
name, and thus also depends on having unique symbols.
Introduce CONFIG_ENFORCE_UNI
l1tf-barrier is an inappropriate name, and came about because of restrictions
on could be discussed publicly when the patches were proposed.
In practice, it is for general Spectre v1 mitigations, and is necessary in all
cases. An adversary which can control speculation in Xen can leak data in
cro
When the compiler can determine that an array bound is a power of two, the
array index can be bounded even under speculation with a single and
instruction.
Respecify array_index_mask_nospec() to allow for masks other than ~0 and 0,
and introduce an IS_POWER_OF_2() helper.
Signed-off-by: Andrew Co
The include of asm/cpuid.h in spec_ctrl.c was an artefact of an older version
of c/s 3860d5534df, and is not used in its current incarnation.
Fix a typo in a comment.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Juergen Gross
v3:
* New
---
xen/arch/
If Xen detects the TSC is unreliable it will set a rendezvous helper
that tries to synchronize the different CPUs TSC value by propagating
the one from CPU#0 and writing it into the IA32_TSC MSR on each CPU.
When the system has a single thread and there are no hotplugable CPUs
doing the above just
flight 143051 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143051/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 143023
test-amd64-amd64-libvir
On 12.10.2019 20:18, Andrew Cooper wrote:
> The xen-ucode utility is new with the late loading improvements in 4.13.
> Update the documentation suitably.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@list
On 19.10.2019 04:04, Andrew Cooper wrote:
> We are now down to 0 SVM maintainers who are active and wish to hold the
> position. In agreement with AMD, Jan and I will take over maintainership in
> the short term.
>
> Signed-off-by: Andrew Cooper
> Acked-by: Boris Ostrovsky
Acked-by: Jan Beulic
On 23.10.2019 14:55, Roger Pau Monné wrote:
> On Wed, Oct 23, 2019 at 02:12:09PM +0200, Juergen Gross wrote:
>> Since commit 8d3c326f6756d1 ("xen: let vcpu_create() select processor")
>> the initial processor for all pv-shim vcpus will be 0, as no other cpus
>> are online when the vcpus are created
On 23.10.19 14:55, Roger Pau Monné wrote:
On Wed, Oct 23, 2019 at 02:12:09PM +0200, Juergen Gross wrote:
Since commit 8d3c326f6756d1 ("xen: let vcpu_create() select processor")
the initial processor for all pv-shim vcpus will be 0, as no other cpus
are online when the vcpus are created. Before t
1 - 100 of 154 matches
Mail list logo
