On 21.10.2019 13:10, George Dunlap wrote:
> On 10/7/19 10:25 AM, Jan Beulich wrote:
>> On 04.10.2019 19:02, George Dunlap wrote:
>>> On 10/2/19 9:11 AM, Jan Beulich wrote:
On 01.10.2019 22:59, Andrew Cooper wrote:
> On 01/10/2019 09:38, Jan Beulich wrote:
>> On 30.09.2019 21:16, Andrew
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 (besides KVM and vfio that are nuts), the
>> pfn_to_online_page() check could most
On 22/10/2019 18:09, Stefano Stabellini wrote:
On Tue, 22 Oct 2019, Stefano Stabellini wrote:
On Tue, 22 Oct 2019, Ben Dooks (Codethink) wrote:
Include for xen_{create,destroy}_contigous_region
call declarations. Fixes the following sparse warnings:
arch/arm/xen/mm.c:119:5: warning: symbol 'x
On Mon, 21 Oct 2019 at 16:59, Wei Liu wrote:
>
> Xen is able to run as a guest on Xen. We plan to make it able to run
> on Hyper-V as well.
>
> Introduce CONFIG_GUEST which is set to true if either running on Xen
> or Hyper-V is desired. Restructure code hierarchy for new code to
> come.
>
> No fu
On 22.10.19 19:12, David Hildenbrand wrote:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
The pages are obtained via get_user_pages_fast(). I assume, these
could be ZONE_DEVICE pages. Let's just exclude them as well explicitly.
Cc: Rob Springer
Cc: Todd Poyno
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 these pages to reserved, we can rework this function to
perform separate checks for ZONE
On Mon, 21 Oct 2019 at 17:01, Wei Liu wrote:
>
> We will soon implement Hyper-V support for Xen. Add a framework for
> that.
>
> This requires moving some of the hypervisor_* functions from xen.h to
> hypervisor.h.
>
> Signed-off-by: Wei Liu
Reviewed-by: Paul Durrant
> ---
> xen/arch/x86/gues
This patch fixes or tries to fix an issue in the configure scripts whereby the
script will choke on systems that do not have a default python executable and
subsequently give a garbage error message.
Now that Python 2 is being phased out, it should be expected that some systems,
at the very lea
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 deletions(-)
diff --git a/tools/configure b/tools/configure
index 82947ad..a
On Mon, 21 Oct 2019 at 17:00, Wei Liu wrote:
>
> Take the chance to change probe_hypervisor to hypervisor_probe.
>
> Signed-off-by: Wei Liu
Reviewed-by: Paul Durrant
> ---
> V3:
> 1. Address Roger's comments
> 2. Change xen_hypervisor_ops to xen_ops
> ---
> xen/arch/x86/guest/hypervisor.c |
On Mon, 21 Oct 2019 at 17:00, Wei Liu wrote:
>
> Signed-off-by: Wei Liu
Reviewed-by: Paul Durrant
> ---
> V3: Address Roger's comment, add ASSERTs
> ---
> xen/arch/x86/guest/hypervisor.c| 6 ++
> xen/arch/x86/setup.c | 6 +-
> xen/include/asm-x86/guest/hyperv
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 vcpu time info when the guest writes to either MSR_IA32_T
On 23.10.19 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 vcpu time inf
On Mon, 21 Oct 2019 at 17:01, Wei Liu wrote:
>
> We use the same code structure as we did for Xen.
>
> As starters, detect Hyper-V in probe routine. More complex
> functionalities will be added later.
>
> Signed-off-by: Wei Liu
Reviewed-by: Paul Durrant
...with one suggestion...
> ---
> V3:
>
On 03.09.2019 20:24, Tamas K Lengyel wrote:
> On Tue, Sep 3, 2019 at 9:53 AM Jan Beulich wrote:
>>
>> On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
>>> @@ -1355,6 +1355,23 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned
>>> int i)
>>> ept = &p2m->ept;
>>> ept->mfn = pag
flight 143029 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143029/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm broken
test-amd64-i386-examine 8 reboot
On 10/23/19 8:27 AM, Jan Beulich wrote:
> On 21.10.2019 13:10, George Dunlap wrote:
>> On 10/7/19 10:25 AM, Jan Beulich wrote:
>>> On 04.10.2019 19:02, George Dunlap wrote:
On 10/2/19 9:11 AM, Jan Beulich wrote:
> On 01.10.2019 22:59, Andrew Cooper wrote:
>> On 01/10/2019 09:38, Jan Be
flight 143058 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143058/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen a7ecdf8139e3646c0eb9c9bd9ed0fe3b344e6fed
baseline version:
xen 59d0
On Wed, Oct 23, 2019 at 08:55:24AM +0100, Paul Durrant wrote:
> On Mon, 21 Oct 2019 at 16:59, Wei Liu wrote:
> >
> > Xen is able to run as a guest on Xen. We plan to make it able to run
> > on Hyper-V as well.
> >
> > Introduce CONFIG_GUEST which is set to true if either running on Xen
> > or Hype
On Wed, Oct 23, 2019 at 10:07:24AM +0100, Paul Durrant wrote:
> On Mon, 21 Oct 2019 at 17:01, Wei Liu wrote:
> >
> > We use the same code structure as we did for Xen.
> >
> > As starters, detect Hyper-V in probe routine. More complex
> > functionalities will be added later.
> >
> > Signed-off-by:
On 23.10.2019 11:37, George Dunlap wrote:
> On 10/23/19 8:27 AM, Jan Beulich wrote:
>> On 21.10.2019 13:10, George Dunlap wrote:
>>> Let's do a cost-benefits analysis of always_inline vs clang_inline.
>>>
>>> For each future gcc version, either it will choose to inline this
>>> function with the `i
On Wed, Oct 23, 2019 at 10:57:39AM +0200, 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 skew
On Wed, Oct 23, 2019 at 11:55:13AM +0100, Wei Liu wrote:
> On Wed, Oct 23, 2019 at 10:57:39AM +0200, 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 calcul
On Wed, Oct 23, 2019 at 01:05:14PM +0200, Roger Pau Monné wrote:
> On Wed, Oct 23, 2019 at 11:55:13AM +0100, Wei Liu wrote:
> > On Wed, Oct 23, 2019 at 10:57:39AM +0200, Roger Pau Monne wrote:
> > > If a HVM/PVH guest writes to MSR_IA32_TSC{_ADJUST} and thus changes
> > > the value of the time stam
flight 143036 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143036/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 142997
build-arm64-pvops 4 h
On 22/10/2019 10:27, Jürgen Groß wrote:
> And now a more sane patch to try.
>
The patch definitely fixes the issue for Null scheduler at least:
Tested-by: Sergey Dyasli
It's still a bit unnerving to have places where sched_set_res() is called
without unit_schedule_lock(), but I hope that's
On Wed, Oct 23, 2019 at 09:11:54AM +, Alexandru Stefan ISAILA wrote:
>
>
> On 03.09.2019 20:24, Tamas K Lengyel wrote:
> > On Tue, Sep 3, 2019 at 9:53 AM Jan Beulich wrote:
> >>
> >> On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
> >>> --- a/xen/include/public/hvm/hvm_op.h
> >>> +++ b/x
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
flight 143042 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143042/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 broken in 143025
test-amd64-amd64-xl-pvshim 18 gue
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 that commit the vcpus
> would have proce
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.
---
tools/libxl/libxl_arm.c | 10 --
1 file changed, 8 insertions(+), 2 del
This should calculate the extra memory needed for shadow and iommu,
the defaults for which depend on values in c_info. So we need this to
have the complete domain config available.
And the defaults should actually be updated and stored. So make it
non-const.
We provide the usual kind of compati
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 through specified in the initial config file.
* "enabled" (and fail if
We need this before we start to figure out the passthrough mode.
I have checked that nothing in libxl__domain_create_info_setdefault
nor the two implementations of ..._arch_... accesses anything else,
other than (i) the domain type (which this function is responsible for
setting and nothing before
According to git log -G:
0x040700 was introduced in 304400459ef0 (aka 4.7.0-rc1~481)
"tools/libxl: rename remus device to checkpoint device"
0x040800 was introduced in 57f8b13c7240 (aka 4.8.0-rc1~437)
"libxl: memory size in kb requires 64 bit variable"
It is surprising that no-one noticed th
I *still* want to sort out the shadow/iommu memory and pci passthrough
situation in 4.13, to avoid promulgating a wrong libxl API in a stable
release.
The only changes since v4 are change the default value name for the
"passthrough" config setting to "default", apropos of the discussion,
and to ad
No functional change. This will let us refer to it in code we are
about to add to this function.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
---
v2: New patch in this version of the series.
---
tools/libxl/libxl_create.c | 17 -
tools/libxl/libxl_dm.c | 7 ++-
too
These are now redundant because shadow_memkb and iommu_memkb are now
defaulted automatically by libxl_domain_need_memory and
libxl_domain_create etc. Callers should not now call these; instead,
they should just let libxl take care of it.
libxl_get_required_shadow_memory was introduced in f89f5558
We are going to change the libxl API in a moment and this change will
make it simpler.
Signed-off-by: Ian Jackson
Reviewed-by: Anthony PERARD
---
tools/xl/xl_vmcontrol.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
i
Defaulting is supposed to be done by libxl. So these calculations
should be here in libxl. libxl__domain_config_setdefault has all the
necessary information including the values of max_memkb and max_vcpus.
The overall functional effect depends on the caller:
For xl, no change. The code moves f
No functional change. This will let us make it into a pointer without
textual change other than to the definition.
While we are here, fix some style errors (missing { }).
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
---
v2: New patch in this version of the series.
---
tools/libxl/libxl_create
Break out this into a new function. We are going to want to call it
from a new call site.
Unfortunately not all of the defaults can be moved into the new
function without changing the order in which things are done. That
does not seem wise at this stage of the release. The effect is that
additi
On 21.10.2019 12:00, Roger Pau Monné wrote:
> On Mon, Sep 30, 2019 at 04:00:42PM +0100, Wei Liu wrote:
>> --- a/xen/include/asm-x86/guest/hypervisor.h
>> +++ b/xen/include/asm-x86/guest/hypervisor.h
>> @@ -36,6 +36,7 @@ bool hypervisor_probe(void);
>> void hypervisor_setup(void);
>> void hypervis
On 23.10.19 15:00, Ian Jackson wrote:
We are going to change the libxl API in a moment and this change will
make it simpler.
Signed-off-by: Ian Jackson
Reviewed-by: Anthony PERARD
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing li
On 23.10.19 15:00, Ian Jackson wrote:
According to git log -G:
0x040700 was introduced in 304400459ef0 (aka 4.7.0-rc1~481)
"tools/libxl: rename remus device to checkpoint device"
0x040800 was introduced in 57f8b13c7240 (aka 4.8.0-rc1~437)
"libxl: memory size in kb requires 64 bit variable
On 23.10.19 15:00, Ian Jackson wrote:
Break out this into a new function. We are going to want to call it
from a new call site.
Unfortunately not all of the defaults can be moved into the new
function without changing the order in which things are done. That
does not seem wise at this stage of
On 23.10.19 15:00, Ian Jackson wrote:
This should calculate the extra memory needed for shadow and iommu,
the defaults for which depend on values in c_info. So we need this to
have the complete domain config available.
And the defaults should actually be updated and stored. So make it
non-cons
On 23.10.19 15:00, Ian Jackson wrote:
No functional change. This will let us make it into a pointer without
textual change other than to the definition.
While we are here, fix some style errors (missing { }).
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
Release-acked-by: Juergen Gross
J
On 23.10.19 15:00, Ian Jackson wrote:
Defaulting is supposed to be done by libxl. So these calculations
should be here in libxl. libxl__domain_config_setdefault has all the
necessary information including the values of max_memkb and max_vcpus.
The overall functional effect depends on the calle
On 23.10.19 15:00, Ian Jackson wrote:
These are now redundant because shadow_memkb and iommu_memkb are now
defaulted automatically by libxl_domain_need_memory and
libxl_domain_create etc. Callers should not now call these; instead,
they should just let libxl take care of it.
libxl_get_required_
On 23.10.19 15:00, Ian Jackson wrote:
We need this before we start to figure out the passthrough mode.
I have checked that nothing in libxl__domain_create_info_setdefault
nor the two implementations of ..._arch_... accesses anything else,
other than (i) the domain type (which this function is re
On 23.10.19 15:00, Ian Jackson wrote:
No functional change. This will let us refer to it in code we are
about to add to this function.
Signed-off-by: Ian Jackson
Acked-by: Wei Liu
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing l
On 23.10.19 15:00, 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
Release-acked-by: Juergen Gross
Juergen
___
On 23.10.19 15:00, 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 through specified in the initia
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
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 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 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
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
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
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/
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
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
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
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
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
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
---
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
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
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 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 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 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 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.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 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 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 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 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:
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:
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:
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
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
__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
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
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-
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
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
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 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
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 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
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 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.
> ---
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 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
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
1 - 100 of 154 matches
Mail list logo
