flight 125120 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125120/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 895b87e38015e0698c6a5c0633e0156b038a56f1
baseline version:
ovmf
flight 125119 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125119/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 125105
Tests which did not
flight 125065 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125065/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125040 pass
in 125065
flight 125117 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125117/
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
On Tue, 10 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 10/07/18 00:02, Stefano Stabellini wrote:
> > On Mon, 9 Jul 2018, Julien Grall wrote:
> > > On 07/07/18 00:11, Stefano Stabellini wrote:
> > > >mfn_t smfn;
> > > >paddr_t start, size;
> > > > +struct membank *bank;
flight 125064 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125064/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu broken
On Tue, 10 Jul 2018, Julien Grall wrote:
> Hi,
>
> On 09/07/18 22:51, Stefano Stabellini wrote:
> > > I would replace this with a BUG_ON(evtchn != 0).
> >
> > I agree with the principle, but I think you meant
> > BUG_ON(d->arch.evtchn_irq <= 0) ?
>
> The IRQ is an unsigned number. So why <= 0?
On Mon, 9 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 07/07/18 00:11, Stefano Stabellini wrote:
> > ... and remove the BUG_ON(!dom0_11_mapping) in allocate_memory.
>
> Please rebase your work on staging. This code has changed a bit since Xen
> 4.11-rc6.
I'll do
> > A follow-up patch
This run is configured for baseline tests only.
flight 74955 xen-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74955/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 15
This run is configured for baseline tests only.
flight 74956 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74956/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c6a14de3ef30291918f3b15436cf6a75db413eea
baseline
On Thu, Jul 5, 2018 at 6:57 AM Juergen Gross wrote:
>
> On 05/07/18 12:19, Juergen Gross wrote:
> > On 04/07/18 20:16, Karl Johnson wrote:
> >> Hello,
> >>
> >> I'm building dom0 kernel RPMs for the CentOS Xen project
> >> (https://github.com/CentOS-virt7/xen-kernel) and it seems that the 4.9
>
On Mon, 2 Jul 2018, Julien Grall wrote:
> Some of the functions implemented in setup.c are only used at boot but
> not yet marked as such.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Stefano Stabellini
>
> ---
> Changes in v2:
> - Add Stefano's reviewed-by
> ---
>
On Mon, 2 Jul 2018, Julien Grall wrote:
> Now that ELF support has been dropped to boot Dom0, no-one is using
> libelf within the hypervisor.
>
> Introduce a config option to select libelf on x86 and keep unselected
> for Arm.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
>
flight 125062 qemu-upstream-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125062/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-install fail REGR. vs. 116784
On Wed, Jul 11, 2018 at 06:07:42AM -0600, Jan Beulich wrote:
> Fam17 replaces CUs by HTs, which we should reflect accordingly, even if
> the difference is not very big. The most relevant change (requiring some
> code restructuring) is that the topoext feature no longer means there is
> a valid CU
08641a9e8870d3b174d95aaa55ecba43387563b5 would be nice to have included.
Stew
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
Jan Beulich
Sent: Wednesday, July 4, 2018 6:42 AM
To: xen-devel
Cc: anthony.per...@citrix.com; Ian Jackson ;
>>> On 11.07.18 at 17:34, wrote:
> Hello,
>
> The following 3 patches allow building the hypervisor with lld 6.0.0.
>
> The only difference between v2 is the split into multiple patches.
>
> Thanks, Roger.
>
> Roger Pau Monne (3):
> xen/x86: replace '||' usage in the linker script
>
On Wed, Jul 11, 2018 at 06:11:36AM -0600, Jan Beulich wrote:
> In the shim case, the number of CPUs should be solely controlled by the
> guest configuration file. Make sure the command line options are fully
> (and not just partially) ignored.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
With '|'. The result is the same, and the later works with lld. Fixes
the following error when building Xen with lld:
ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \
/root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0
ld: error: xen.lds:260: malformed
This allows removing the DEFINED conditional in the linker script, and
fixes compilation with lld:
ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \
/root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0
ld: error: xen.lds:233: symbol not found: efi
And replace the open-coded versions already in tree. No functional
change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Daniel Kiper
---
xen/include/xen/compiler.h | 2 ++
xen/include/xen/livepatch_payload.h | 4 ++--
2 files changed, 4 insertions(+), 2
Hello,
The following 3 patches allow building the hypervisor with lld 6.0.0.
The only difference between v2 is the split into multiple patches.
Thanks, Roger.
Roger Pau Monne (3):
xen/x86: replace '||' usage in the linker script
xen/compiler: introduce a define for weak symbols
xen/x86:
On 07/11/2018 01:08 AM, Juergen Gross wrote:
> On 11/07/18 00:26, Boris Ostrovsky wrote:
>> On 07/02/2018 06:00 AM, Juergen Gross wrote:
>>> Setting pv_irq_ops for Xen PV domains should be done as early as
>>> possible in order to support e.g. very early printk() usage.
>> Will printk() work as
On Wed, Jul 11, 2018 at 06:11:36AM -0600, Jan Beulich wrote:
> In the shim case, the number of CPUs should be solely controlled by the
> guest configuration file. Make sure the command line options are fully
> (and not just partially) ignored.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Rich Persaud
> Sent: 11 July 2018 15:06
> To: Xen-devel
> Cc: committ...@xenproject.org; Lars Kurth ;
> car...@cardoe.com; George Dunlap ; Tamas K
> Lengyel
> Subject: Re: [Xen-devel]
This quietens the output again.
Signed-off-by: Ian Jackson
---
Osstest/PDU/ipmi.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Osstest/PDU/ipmi.pm b/Osstest/PDU/ipmi.pm
index f3a50c9..b6621db 100644
--- a/Osstest/PDU/ipmi.pm
+++ b/Osstest/PDU/ipmi.pm
@@ -50,11
This is useful, for example, for passing `-I lanplus'.
Signed-off-by: Ian Jackson
---
Osstest/PDU/ipmi.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Osstest/PDU/ipmi.pm b/Osstest/PDU/ipmi.pm
index b6621db..d411d97 100644
--- a/Osstest/PDU/ipmi.pm
+++ b/Osstest/PDU/ipmi.pm
@@ -50,6
This allows arguments with spaces, etc.
No functional change with the existing configurations I know about.
It would be good to fix this before any configurations are created
where this would make a difference...
Signed-off-by: Ian Jackson
---
Osstest/PDU/ipmi.pm | 14 ++
1 file
For debugging.
Signed-off-by: Ian Jackson
---
Osstest/PDU/pause.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/Osstest/PDU/pause.pm b/Osstest/PDU/pause.pm
index 9e839c6..b5f0322 100644
--- a/Osstest/PDU/pause.pm
+++ b/Osstest/PDU/pause.pm
@@ -46,6 +46,7 @@ sub new {
sub
Previously this was hardcoded. Now we make a variable @ssh, and use
rsync's quoting scheme to transform it into a value suitable for -e.
No overall functional change, although now the rsync command contains
additional quotes in the -e option.
Signed-off-by: Ian Jackson
---
And delete the explicit settings from production-config.
No functional change.
Signed-off-by: Ian Jackson
---
Osstest.pm| 4 ++--
production-config | 3 ---
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/Osstest.pm b/Osstest.pm
index 3377ea3..738ed4f 100644
---
We need to pass it $cfgbase because this will soon be configurable.
No functional change right now.
Signed-off-by: Ian Jackson
---
Osstest/Management.pm | 10 --
cr-publish-flight-logs | 3 ++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/Osstest/Management.pm
From: Ian Jackson
We finally have a VM host for publishing the test logs from the Citrix
instance of osstest. It needs an ssh bounce to get to the actual
public webserver, so we add support for that.
With this, and appropriate ssh keys, osst...@osstest.xs can run
cr-publish-flight-logs,
Signed-off-by: Ian Jackson
---
Osstest.pm| 1 +
Osstest/Management.pm | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Osstest.pm b/Osstest.pm
index 738ed4f..85a6e78 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -257,6 +257,7 @@ END
my $u = ucfirst $l;
This URL is now accessible, although there are some webserver tweaks
remaining to do.
Signed-off-by: Ian Jackson
---
production-config-cambridge | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/production-config-cambridge b/production-config-cambridge
index b1360ba..8647feb
Have it take $cfgbase and $subdir instead. This allows us to lift the
config test into it. And it will be even more useful in a moment.
No functional change.
Signed-off-by: Ian Jackson
---
cr-publish-flight-logs | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
Signed-off-by: Ian Jackson
---
production-config-cambridge | 3 +++
1 file changed, 3 insertions(+)
diff --git a/production-config-cambridge b/production-config-cambridge
index f557614..b1360ba 100644
--- a/production-config-cambridge
+++ b/production-config-cambridge
@@ -41,6 +41,9 @@
Signed-off-by: Ian Jackson
---
cr-ensure-disk-space | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/cr-ensure-disk-space b/cr-ensure-disk-space
index 7091314..3e0288f 100755
--- a/cr-ensure-disk-space
+++ b/cr-ensure-disk-space
@@ -25,6 +25,7 @@ BEGIN { unshift @INC,
On Jul 5, 2018, at 22:54, Tamas K Lengyel wrote:
>
>> On Thu, Jul 5, 2018 at 12:52 PM George Dunlap
>> wrote:
>>
>>>
Again, there was a sense that some of the issues we are seeing could be
solved if we had better
CI capability: in other words, some of the issues we were
>>> On 11.07.18 at 15:46, wrote:
> At 07:29 -0600 on 11 Jul (1531294179), Jan Beulich wrote:
>> This isn't as much of an optimization than to avoid triggering a gcc bug
>> affecting 5.x ... 7.x, triggered by any asm() put inside the ad hoc
>> "rewalk" loop and taking as an (output?) operand a
>>> On 11.07.18 at 15:42, wrote:
> This is intentionally not touching hooks used rarely (or not at all)
> during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
> as well as nested, VM event, and altp2m ones (they can all be done
> later, if so desired). Virtual Interrupt delivery
For now only the ones used during entering/exiting of idle states are
converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
be converted, as they may get established rather late (when Dom0 is
already active).
Note that for patching to be deferred until after the pre-SMP initcalls
At 07:29 -0600 on 11 Jul (1531294179), Jan Beulich wrote:
> This isn't as much of an optimization than to avoid triggering a gcc bug
> affecting 5.x ... 7.x, triggered by any asm() put inside the ad hoc
> "rewalk" loop and taking as an (output?) operand a register variable
> tied to %rdx (an "rdx"
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -29,12 +29,12 @@
void send_IPI_mask(const cpumask_t *mask, int vector)
{
-genapic.send_IPI_mask(mask, vector);
+
Instead of loading a pointer at each use site, have a single runtime
instance of struct genapic, copying into it from the individual
instances. The individual instances can this way also be moved to .init
(also adjust apic_probe[] at this occasion).
Signed-off-by: Jan Beulich
---
All flavors specify target_cpus_all() anyway - replace use of the hook
by _online_map.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/genapic/delivery.c
+++ b/xen/arch/x86/genapic/delivery.c
@@ -5,12 +5,6 @@
#include
#include
-
-const cpumask_t *target_cpus_all(void)
-{
- return
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -196,7 +196,7 @@ void ctxt_switch_levelling(const struct
}
if (ctxt_switch_masking)
- ctxt_switch_masking(next);
+ alternative_vcall1(ctxt_switch_masking,
While not strictly necessary, change the VMX initialization logic to
update the function table in start_vmx() from NULL rather than to NULL,
to make more obvious that we won't ever change an already (explictly)
initialized function pointer.
Signed-off-by: Jan Beulich
---
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
as well as nested, VM event, and altp2m ones (they can all be done
later, if so desired). Virtual Interrupt delivery ones will be dealt
with in a subsequent
In a number of cases the targets of indirect calls get determined once
at boot time. In such cases we can replace those calls with direct ones
via our alternative instruction patching mechanism.
Some of the targets (in particular the hvm_funcs ones) get established
only in pre-SMP initcalls,
As was validly pointed out as motivation for similar Linux side changes
(https://lkml.org/lkml/2018/6/22/677), using long sequences of
directives and auxiliary instructions, like is commonly the case when
setting up an alternative patch site, gcc can be mislead into believing
an asm() to be more
This isn't as much of an optimization than to avoid triggering a gcc bug
affecting 5.x ... 7.x, triggered by any asm() put inside the ad hoc
"rewalk" loop and taking as an (output?) operand a register variable
tied to %rdx (an "rdx" clobber is fine). The issue is due to an apparent
collision in
Since the generic pattern rules don't match those, explicit rules need
to be put in place for this to work.
Signed-off-by: Jan Beulich
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -249,6 +249,17 @@ FORCE:
%/: FORCE
$(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
It's used in quite a few places, and hence doing so eases subsequent
adjustment to how these (indirect) calls are carried out.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/domain.c
+++ b/xen/arch/x86/hvm/domain.c
@@ -317,9 +317,9 @@ int arch_set_info_hvm_guest(struct vcpu
/* Sync
Commit a1b1572833 ("VMX: add VMFUNC leaf 0 (EPTP switching) to
emulator") needlessly introduced it, and no user has appeared since.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -76,7 +76,6 @@ static void vmx_fpu_dirty_intercept(void
static int
From: Suravee Suthikulpanit
This patch modifies the hvm_funcs.virtual_intr_delivery_enabled()
to become a bool variable as VMX does and SVM will simply return a
static value.
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Jan Beulich
---
Extracted from an SVM/AVIC series patch.
---
Instead of checking hvm_tsc_scaling_supported inside the hook function,
install the hook only when setting state such that said predicate
becomes true.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1283,7 +1283,7 @@ static void
Three of the four hooks are not exposed outside of vmx.c, and all of
them have only a single possible non-NULL value. So there's no reason to
use hooks here - a simple set of flag indicators is sufficient (and we
don't even need a flag for the VM entry one, as it's always
(de-)activated together
flight 125104 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125104/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 784d607328d1205ced136be9f87c76ee51bcac5e
baseline version:
freebsd
Install nasm and build ovmf with gcc on x86.
Signed-off-by: Wei Liu
---
I have tested stretch 64 bit and 32 bit containers.
I haven't tested the build script itself.
---
automation/build/centos/7.2.dockerfile | 1 +
automation/build/debian/jessie.dockerfile | 1 +
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 11 July 2018 14:05
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; Ian Jackson ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Tim
> (Xen.org) ;
On 07/11/2018 01:31 PM, Paul Durrant wrote:
>>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
>>> index c6b99c4116..510f37f100 100644
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -375,39 +375,23 @@ static int get_paged_frame(unsigned long gfn,
>>
Ian Jackson writes ("[PATCH] xen/Makefile: Bump version to 4.11.1-pre for
ongoing 4.11 stable branch"):
> I will push this change on Wednesday, after 4.11 is released, and then
> 4.11 can be handed over to the stable maintainers.
Now done. staging-4.11 is open for business.
Ian.
flight 125059 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125059/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR.
vs. 124994
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 11 July 2018 12:46
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Julien
> Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ;
>>> On 11.07.18 at 13:57, wrote:
> On Tue, Jul 10, 2018 at 08:05:56AM -0600, Jan Beulich wrote:
>> >>> On 10.07.18 at 13:35, wrote:
>> > On Fri, Jul 06, 2018 at 09:16:38AM -0600, Jan Beulich wrote:
>> >> >>> On 06.07.18 at 16:46, wrote:
>> >> > OK, xen.mb.efi does not need relocs because:
>> >>
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 11 July 2018 12:24
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Julien
> Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ;
>>> On 11.07.18 at 13:41, wrote:
> On Tue, Jul 10, 2018 at 07:54:51AM -0600, Jan Beulich wrote:
>> >>> On 10.07.18 at 12:48, wrote:
>> > On Fri, Jul 06, 2018 at 09:08:29AM -0600, Jan Beulich wrote:
>> >> >>> On 06.07.18 at 16:02, wrote:
>> >> > On Thu, Jul 05, 2018 at 02:18:03AM -0600, Jan
> -Original Message-
> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
> George Dunlap
> Sent: 11 July 2018 11:52
> To: Paul Durrant
> Cc: xen-devel ; Kevin Tian
> ; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v2 09/13] vtd: add lookup_page method to
> iommu_ops
>
> On
On 11/07/18 13:11, Jan Beulich wrote:
> In the shim case, the number of CPUs should be solely controlled by the
> guest configuration file. Make sure the command line options are fully
> (and not just partially) ignored.
>
> Signed-off-by: Jan Beulich
Ideally with "This option is ignored in
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 11 July 2018 11:34
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.org) ;
On 11/07/18 13:12, Jan Beulich wrote:
> Drop unnecessary casts and use bool in favor of bool_t.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Drop unnecessary casts and use bool in favor of bool_t.
Signed-off-by: Jan Beulich
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -345,9 +345,9 @@ static inline int cpulist_scnprintf(char
typedef cpumask_t *cpumask_var_t;
-static inline bool_t
Shared resources (L1 cache and TLB in particular) present a risk of
information leak via side channels. Don't use hyperthreads in such
cases, but allow independent control of their use at the same time.
Signed-off-by: Jan Beulich
---
An option to avoid the up/down cycle would be to avoid
Reportedly Intel CPUs which can't broadcast #MC to all targeted
cores/threads because some have CR4.MCE clear will shut down. Therefore
we want to keep CR4.MCE enabled when offlining a CPU, and we need to
bring up all CPUs in order to be able to set CR4.MCE in the first place.
The use of
On Wed, Jul 11, 2018 at 01:13:18PM +0200, Michal Hocko wrote:
> On Wed 11-07-18 13:14:47, Leon Romanovsky wrote:
> > On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote:
> > > On Tue 10-07-18 19:20:20, Leon Romanovsky wrote:
> > > > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko
Fam17 replaces CUs by HTs, which we should reflect accordingly, even if
the difference is not very big. The most relevant change (requiring some
code restructuring) is that the topoext feature no longer means there is
a valid CU ID.
Take the opportunity and convert wrongly plain int variables in
The function's use of the stop-machine logic has so far prevented its
use ahead of the processing of the "ordinary" initcalls. Since at this
early time we're in a controlled environment anyway, there's no need for
such a heavy tool. Additionally this ought to have less of a performance
impact
In order to be able to service #MC on offlined CPUs, GDT, IDT, stack,
and per-CPU data (which includes the TSS) need to be kept allocated.
They should only be freed upon CPU removal (which we currently don't
support, so some code is becoming effectively dead for the moment).
Signed-off-by: Jan
While I've run into the issue with further patches in place which no
longer guarantee the per-CPU area to start out as all zeros, the
CPU_DOWN_FAILED processing looks to have the same issue: By not zapping
the per-CPU cpupool pointer, cpupool_cpu_add()'s (indirect) invocation
of
On Wed, Jul 11, 2018 at 01:46:56PM +0200, Roger Pau Monné wrote:
> On Wed, Jul 11, 2018 at 12:42:48PM +0200, Daniel Kiper wrote:
> > On Wed, Jul 11, 2018 at 12:25:21PM +0200, Roger Pau Monne wrote:
> > > lld (the llvm linker) has some issues with Xen linker script. It
> > > doesn't understand '||'
On Tue, Jul 10, 2018 at 08:05:56AM -0600, Jan Beulich wrote:
> >>> On 10.07.18 at 13:35, wrote:
> > On Fri, Jul 06, 2018 at 09:16:38AM -0600, Jan Beulich wrote:
> >> >>> On 06.07.18 at 16:46, wrote:
> >> > OK, xen.mb.efi does not need relocs because:
> >> > - we generate PE file from xen-syms
I've been considering to add a respective command line option for
quite a long time, but never got around to. Now that the TLBleed
information is public[1], we're at point where we not only want,
but need this, and where perhaps it needs to be the default on
affected systems. The first 5 patches
flight 125105 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125105/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c6a14de3ef30291918f3b15436cf6a75db413eea
baseline version:
ovmf
This run is configured for baseline tests only.
flight 74954 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74954/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-build
On 07/07/2018 12:05 PM, Paul Durrant wrote:
> This patch adds iommu_ops to add (map) or remove (unmap) frames in the
> domain's IOMMU mappings, and an iommu_op to synchronize (flush) those
> manipulations with the hardware.
>
> Mappings added by the map operation are tracked and only those
On Tue, Jul 10, 2018 at 07:54:51AM -0600, Jan Beulich wrote:
> >>> On 10.07.18 at 12:48, wrote:
> > On Fri, Jul 06, 2018 at 09:08:29AM -0600, Jan Beulich wrote:
> >> >>> On 06.07.18 at 16:02, wrote:
> >> > On Thu, Jul 05, 2018 at 02:18:03AM -0600, Jan Beulich wrote:
> >> >> >>> On 04.07.18 at
On 07/07/2018 12:05 PM, Paul Durrant wrote:
> ...for some uses of get_page_from_gfn().
>
> There are many occurences of the following pattern in the code:
>
> q = ? P2M_ALLOC : P2M_UNSHARE;
> page = get_page_from_gfn(d, gfn, , q);
>
> if ( p2m_is_paging(p2mt) )
> {
> if
On Wed 11-07-18 13:14:47, Leon Romanovsky wrote:
> On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote:
> > On Tue 10-07-18 19:20:20, Leon Romanovsky wrote:
> > > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote:
> > > > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote:
> > > >
flight 125057 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125057/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 124880
test-xtf-amd64-amd64-2 50
On Sat, Jul 7, 2018 at 12:05 PM, Paul Durrant wrote:
> This patch adds a new method to the VT-d IOMMU implementation to find the
> MFN currently mapped by the specified BFN along with a wrapper function in
> generic IOMMU code to call the implementation if it exists.
>
> This functionality will
On Wed, Jul 11, 2018 at 12:25:21PM +0200, Roger Pau Monne wrote:
> lld (the llvm linker) has some issues with Xen linker script. It
> doesn't understand '||' in assert expressions:
>
> ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \
> /root/src/xen/xen/common/symbols-dummy.o
flight 125103 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125103/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen f5d10dc2909c84e4ffc7240e542c513ed480aa04
baseline version:
xen
On 07/07/2018 12:05 PM, Paul Durrant wrote:
> @@ -35,17 +93,33 @@ static void iommu_op(xen_iommu_op_t *op)
>
> int do_one_iommu_op(xen_iommu_op_buf_t *buf)
> {
> -xen_iommu_op_t op;
> +xen_iommu_op_t op = {};
> +size_t offset;
> +static const size_t op_size[] = {
> +
flight 125101 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125101/
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
lld (the llvm linker) has some issues with Xen linker script. It
doesn't understand '||' in assert expressions:
ld-melf_x86_64_fbsd -T xen.lds -N prelink.o --build-id=sha1 \
/root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0
ld: error: xen.lds:260: malformed
On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote:
> On Tue 10-07-18 19:20:20, Leon Romanovsky wrote:
> > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote:
> > > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote:
> > > > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko
Dear xen expert：
From the blocked information, we found that the CPU 14 and CPU 19 is
blocked, and the call trace is mainly about:
[68915.792526] [] on_each_cpu+0x28/0x60
[68915.792540] [] decrease_reservation+0x261/0x2f0
[68915.792555] [] alloc_xenballooned_pages+0xe6/0x180
On Wed, 2018-07-11 at 11:46 +0200, Juergen Gross wrote:
> On 11/07/18 11:15, Woodhouse, David wrote:
> >
> > On Wed, 2018-05-30 at 13:09 +0200, Juergen Gross wrote:
> > >
> > > There is no need to set the same capabilities for each cpu
> > > individually. This can easily be done for all cpus
1 - 100 of 122 matches
Mail list logo
