With current staging, qemu-xen fails to build. It looks like a ordering
issue, I assume ui/input-keymap-linux-to-qcode.c is a generated file.
It is (as always) a fresh clean checkout in a clean chroot.
[ 505s]
/home/abuild/rpmbuild/BUILD/xen-4.11.20180206T183258.30cbd0c83e/non-dbg/tools/qemu-xen
HVC is shown underlined, the underscores are missing.
Fix it by using underscores.
Remove stale I.
Signed-off-by: Olaf Hering
---
docs/man/xen-pv-channel.pod.7 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/man/xen-pv-channel.pod.7 b/docs/man/xen-pv-channel.pod.7
index
The previous version simply states that a symlink has to be created
without telling where the symlink should point to.
Signed-off-by: Olaf Hering
---
docs/man/xen-pv-channel.pod.7 | 2 ++
1 file changed, 2 insertions(+)
diff --git a/docs/man/xen-pv-channel.pod.7 b/docs/man/xen-pv-channel.pod.7
>>> On 06.02.18 at 22:51, wrote:
> The problem with a quirk/commandline parameter is that the issue is
> reported for a wide variety of systems and, as it looks like, depends on
> the default BIOS setup - means it's hard to identify particular
> machines. We should obviously sort this out with Int
On 02/06/2018 10:39 PM, Dario Faggioli wrote:
> On Tue, 2018-02-06 at 17:02 +, George Dunlap wrote:
>> On 02/06/2018 06:18 AM, Juergen Gross wrote:
>>> On 05/02/18 17:53, Dario Faggioli wrote:
Considering we're releasing in June, but freezing in March, do we
think
it is sti
>>> On 07.02.18 at 09:18, wrote:
> With current staging, qemu-xen fails to build. It looks like a ordering
> issue, I assume ui/input-keymap-linux-to-qcode.c is a generated file.
> It is (as always) a fresh clean checkout in a clean chroot.
I think I had seen this too, and only then I realized th
Am Wed, 07 Feb 2018 02:56:55 -0700
schrieb "Jan Beulich" :
> I think I had seen this too, and only then I realized that now I need
> to set up the respective submodule in the qemu tree.
Yes, it looks like qemu has now submodules which are required for build.
Neither configure nor 'git archive' d
flight 118635 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118635/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 30cbd0c83ef3d0edac2d5bcc41a9a2b7a843ae58
baseline version:
xen 99d9
On Tue, Feb 06, 2018 at 09:56:14PM +, Michael Young wrote:
> On Tue, 6 Feb 2018, Wei Liu wrote:
>
> > On Tue, Jan 30, 2018 at 10:55:47PM +, Michael Young wrote:
> > > Xen built with ocaml 4.06 gives errors such as
> > > Error: This expression has type bytes but an expression was
> > > ex
On Wed, Feb 07, 2018 at 09:30:57AM +0100, Olaf Hering wrote:
> HVC is shown underlined, the underscores are missing.
> Fix it by using underscores.
> Remove stale I.
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-deve
On Wed, Feb 07, 2018 at 09:45:53AM +0100, Olaf Hering wrote:
> The previous version simply states that a symlink has to be created
> without telling where the symlink should point to.
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
___
Xen-devel mai
>>> On 06.02.18 at 12:09, wrote:
> During patching, there is a very slim risk that an NMI or MCE interrupt in the
> middle of altering the code in the NMI/MCE paths, in which case bad things
> will happen.
>
> The NMI risk can be eliminated by running the patching loop in NMI context, at
> which
So it can be used by both gcc and clang. Just add the Kconfig option
and modify the makefiles so the llvm coverage specific code can be
added in a follow up patch.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
On Wed, Feb 07, 2018 at 10:53:56AM +, Roger Pau Monne wrote:
> So it can be used by both gcc and clang. Just add the Kconfig option
> and modify the makefiles so the llvm coverage specific code can be
> added in a follow up patch.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
__
On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
> Hey folks,
>
> Presented herewith is an attempt to implement PV backends feature control
> as discussed in the list
> (https://lists.xen.org/archives/html/xen-devel/2017-09/msg00766.html)
>
> Given that this a simple proposal hence
On 07/02/18 12:16, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
>> Hey folks,
>>
>> Presented herewith is an attempt to implement PV backends feature control
>> as discussed in the list
>> (https://lists.xen.org/archives/html/xen-devel/2017-09/msg00766.htm
flight 118629 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail REGR. vs. 118324
test-amd64-amd64-xl
On Wed, Feb 07, 2018 at 12:20:42PM +0100, Juergen Gross wrote:
> On 07/02/18 12:16, Roger Pau Monné wrote:
> > On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
> >> * Toolstack constructs a key value store of features, and user specifies
> >> those
> >> through special entry names pre
On 02/07/2018 11:30 AM, Roger Pau Monné wrote:
> On Wed, Feb 07, 2018 at 12:20:42PM +0100, Juergen Gross wrote:
>> On 07/02/18 12:16, Roger Pau Monné wrote:
>>> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
* Toolstack constructs a key value store of features, and user specifie
On Thu, Nov 02, 2017 at 06:06:09PM +, Joao Martins wrote:
> The proposed directory provides a mechanism for tools to control the
> maximum feature set of the device being provisioned by backends.
> Examples include max ring page order, persistent grants, number of
> queues etc.
>
> Signed-off-
On 02/07/2018 11:30 AM, Roger Pau Monné wrote:
> On Wed, Feb 07, 2018 at 12:20:42PM +0100, Juergen Gross wrote:
>> On 07/02/18 12:16, Roger Pau Monné wrote:
>>> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
* Toolstack constructs a key value store of features, and user specifie
On Thu, Nov 02, 2017 at 06:06:15PM +, Joao Martins wrote:
> Toolstack may write values to the "require" subdirectory in the
> backend main directory (e.g. backend/vbd/X/Y/). Read these values
> and use them when announcing those to the frontend. When backend
> scans frontend features the values
On 02/07/2018 11:16 AM, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 06:06:08PM +, Joao Martins wrote:
>> Hey folks,
>>
>> Presented herewith is an attempt to implement PV backends feature control
>> as discussed in the list
>> (https://lists.xen.org/archives/html/xen-devel/2017-09/msg0076
On 02/06/2018 05:12 PM, Wei Liu wrote:
> (Three months after you sent this, sorry...)
>
> On Mon, Nov 06, 2017 at 12:33:06PM +, Joao Martins wrote:
>> On Mon, Nov 06, 2017 at 10:33:59AM +, Paul Durrant wrote:
-Original Message-
From: Joao Martins [mailto:joao.m.mart...@or
On 02/06/2018 02:52 PM, Wei Liu wrote:
On Tue, Feb 06, 2018 at 02:44:56PM +0200, Oleksandr Andrushchenko wrote:
From aa1f20af73a5a3c8f2c904b857a79334d18d41ff Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko
Date: Wed, 20 Dec 2017 17:51:18 +0200
Subject: [PATCH] [HACK] Reset iomem's gfn
flight 118630 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118630/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 118613
test-armhf-armhf-libvirt 14 sav
Hi,
On 06/02/18 19:56, Julien Grall wrote:
Xen does not yet support Cavium SMMU because it requires some
workaround. For the time being, blacklist them.
Signed-off-by: Julien Grall
---
xen/arch/arm/platforms/Makefile | 1 +
xen/arch/arm/platforms/thunderx.c | 39 +
Am Wed, 7 Feb 2018 11:13:22 +0100
schrieb Olaf Hering :
> Yes, it looks like qemu has now submodules which are required for build.
How is the required state of the submodules tracked? When I did a local build I
got 10739aa from qemu.org, and building xen.git#staging succeeds. After that I
updat
>>> On 07.02.18 at 13:40, wrote:
> Am Wed, 7 Feb 2018 11:13:22 +0100
> schrieb Olaf Hering :
>
>> Yes, it looks like qemu has now submodules which are required for build.
>
> How is the required state of the submodules tracked? When I did a local
> build I got 10739aa from qemu.org, and buildin
flight 118632 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118632/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 118605
test-armhf-armhf-libvirt-xsm 14 saveresto
On 07/02/18 09:13, Jan Beulich wrote:
On 06.02.18 at 22:51, wrote:
>> The problem with a quirk/commandline parameter is that the issue is
>> reported for a wide variety of systems and, as it looks like, depends on
>> the default BIOS setup - means it's hard to identify particular
>> machines.
>>> On 07.02.18 at 14:01, wrote:
> So far the issue confirmed:
> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
> that it was tested on), Intel S2600XX, etc.
>
> Also see:
> https://bugs.xenserver.org/browse/XSO-774
>
> Well, no-watchdog is what we currently recommend in t
On 07/02/18 13:08, Jan Beulich wrote:
On 07.02.18 at 14:01, wrote:
>> So far the issue confirmed:
>> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>> that it was tested on), Intel S2600XX, etc.
>>
>> Also see:
>> https://bugs.xenserver.org/browse/XSO-774
>>
>> Well, no
Hi Julien,
On 6 February 2018 at 20:04, Julien Grall wrote:
> Hi,
>
> On 02/06/2018 04:18 PM, Volodymyr Babchuk wrote:
>>
>> On 5 February 2018 at 15:20, Julien Grall wrote:
>>>
>>> The new SMC Calling Convention (v1.1) allows for a reduced overhead when
>>> calling into the firmware, and provid
Hi Julien,
On 6 February 2018 at 20:33, Julien Grall wrote:
> Hi,
>
> On 02/06/2018 04:36 PM, Volodymyr Babchuk wrote:
>>
>> On 5 February 2018 at 15:20, Julien Grall wrote:
>>>
>>> The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for
>>> hardening the branch predictor. So we wa
Hi,
On 6 February 2018 at 20:12, Julien Grall wrote:
> On 02/06/2018 04:23 PM, Volodymyr Babchuk wrote:
>>
>> Hi,
>
>
> Hi,
>
>> On 5 February 2018 at 15:20, Julien Grall wrote:
>>>
>>> SMCCC 1.1 offers firmware-based CPU workarounds. In particular,
>>> SMCCC_ARCH_WORKAROUND_1 provides BP harden
flight 118631 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118631/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
On 07/02/18 13:08, Jan Beulich wrote:
On 07.02.18 at 14:01, wrote:
>> So far the issue confirmed:
>> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>> that it was tested on), Intel S2600XX, etc.
>>
>> Also see:
>> https://bugs.xenserver.org/browse/XSO-774
>>
>> Well, no
On 02/07/2018 12:08 PM, Roger Pau Monné wrote:
> On Thu, Nov 02, 2017 at 06:06:15PM +, Joao Martins wrote:
>> Toolstack may write values to the "require" subdirectory in the
>> backend main directory (e.g. backend/vbd/X/Y/). Read these values
>> and use them when announcing those to the fronten
flight 118641 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 118626
build-armhf
On Wed, Feb 07, 2018 at 02:16:14PM +, Joao Martins wrote:
> On 02/07/2018 12:08 PM, Roger Pau Monné wrote:
> > On Thu, Nov 02, 2017 at 06:06:15PM +, Joao Martins wrote:
> >> +static void xen_blkbk_probe_features(struct xenbus_device *dev,
> >> + struct backend_
Explicit segment overides other than %fs and %gs are documented as ignored by
both Intel and AMD.
In practice, this means that:
* Explicit uses of %ss don't actually yield #SS[0] for non-canonical
memory references.
* Explicit uses of %{e,c,d}s don't override %rbp/%rsp-based memory reference
On Wed, Feb 07, 2018 at 01:40:04PM +0100, Olaf Hering wrote:
> Am Wed, 7 Feb 2018 11:13:22 +0100
> schrieb Olaf Hering :
>
> > Yes, it looks like qemu has now submodules which are required for build.
>
> How is the required state of the submodules tracked?
Hi,
QEMU have now a script to take car
This is a split of the RFC with the mkdir fix added, but with the symlink
handling left off for now (I'll need some more time to properly deal with
that without using -xtype, ideally treating absolute and relative ones
differently).
1: correctly handle errors during Xen tree setup
2: better filter
"set -e" on a separate Makefile line is meaningless. Glue together all
the lines that this is supposed to cover.
Signed-off-by: Jan Beulich
--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -16,18 +16,18 @@ DEP_FILES=$(foreach i, $(LINK_FILES), $(
linkfarm.stamp:
>>> On 07.02.18 at 14:24, wrote:
> On 07/02/18 13:08, Jan Beulich wrote:
> On 07.02.18 at 14:01, wrote:
>>> So far the issue confirmed:
>>> Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
>>> that it was tested on), Intel S2600XX, etc.
>>>
>>> Also see:
>>> https://bugs.x
I have no idea what *.d1 is supposed to refer to - we only have .*.d
and .*.d2 files (note also the leading dot).
Signed-off-by: Jan Beulich
--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -26,7 +26,7 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES)
$(foreach d,
I have no idea what *.1 is meant to cover. Instead also exclude
preprocessed and non-source assembly files.
Signed-off-by: Jan Beulich
--- unstable.orig/tools/firmware/xen-dir/Makefile 2018-02-07
15:30:24.038600788 +0100
+++ unstable/tools/firmware/xen-dir/Makefile2018-02-07 15:35:18.
"mkdir -p" reports a missing operand, as config/ has no subdirs. Oddly
enough this doesn't cause the whole command (and hence the build to
fail), despite the "set -e" now covering the entire set of commands -
perhaps a quirk of the relatively old bash I've seen this with (a few
simple experiments s
Remove the executable bits of vtpm files by using _DATA instead of _PROG.
Signed-off-by: Olaf Hering
---
stubdom/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index f45eeabd8b..7cb62e6c36 100644
--- a/stubdom/Makefile
+++ b/s
>>> On 07.02.18 at 15:41, wrote:
> Explicit segment overides other than %fs and %gs are documented as ignored by
> both Intel and AMD.
>
> In practice, this means that:
>
> * Explicit uses of %ss don't actually yield #SS[0] for non-canonical
>memory references.
> * Explicit uses of %{e,c,d
On Wed, Feb 07, 2018 at 02:44:05PM +, Anthony PERARD wrote:
> On Wed, Feb 07, 2018 at 01:40:04PM +0100, Olaf Hering wrote:
> > Am Wed, 7 Feb 2018 11:13:22 +0100
> > schrieb Olaf Hering :
> >
> > > Yes, it looks like qemu has now submodules which are required for build.
> >
> > How is the requ
>>> On 20.12.17 at 10:37, wrote:
> The parts of this series aren't really dependent upon one another,
> they belong together solely because of their origin.
>
> 1: x86/shadow: widen reference count
> 2: x86/mm: clean up SHARED_M2P{,_ENTRY} uses
> 3: x86: use paging_mark_pfn_dirty()
George,
any
>>> On 07.02.18 at 11:53, wrote:
> docs/misc/coverage.markdown | 2 +-
> xen/Kconfig.debug| 6 +++---
> xen/Rules.mk | 9 +++--
> xen/arch/x86/efi/Makefile| 2 +-
> xen/common/Makefile | 2 +-
> xen/common/coverage/Makefile | 5 -
> xen/common/sys
On Mon, Jan 29, 2018 at 2:18 AM, Jan Beulich wrote:
On 26.01.18 at 18:35, wrote:
>> On Fri, Jan 26, 2018 at 5:46 AM, Jan Beulich wrote:
>> On 23.01.18 at 01:21, wrote:
@@ -375,12 +385,39 @@ static void __init PrintErrMesg(const CHAR16 *mesg,
EFI_STATUS ErrCode)
st
1: slightly reduce Meltdown band-aid overhead
2: remove CR reads from exit-to-guest path
3: introduce altinstruction_nop assembler macro
4: NOP out most XPTI entry/exit code when it's not in use
5: avoid double CR3 reload when switching to guest user mode
6: disable XPTI when RDCL_NO
7: x86: log XP
On Wed, Feb 07, 2018 at 08:07:40AM -0700, Jan Beulich wrote:
> I have no idea what *.d1 is supposed to refer to - we only have .*.d
> and .*.d2 files (note also the leading dot).
>
> Signed-off-by: Jan Beulich
>
> --- a/tools/firmware/xen-dir/Makefile
> +++ b/tools/firmware/xen-dir/Makefile
> @@
On Wed, Feb 07, 2018 at 08:07:01AM -0700, Jan Beulich wrote:
> "set -e" on a separate Makefile line is meaningless. Glue together all
> the lines that this is supposed to cover.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
I'm not sure why I didn't do this right away: By avoiding the use of
global PTEs in the cloned directmap, there's no need to fiddle with
CR4.PGE on any of the entry paths. Only the exit paths need to flush
global mappings.
The reduced flushing, however, implies that we now need to have
interrupts
This allows shortening (and making more obvious what they do) some
altinstruction_entry uses.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -135,8 +135,7 @@ ENTRY(compat_restore_all_guest)
jne 1b
.Lcr4_alt_end:
CR3 is - during normal operation - only ever loaded from v->arch.cr3,
so there's no need to read the actual control register. For CR4 we can
generally use the cached value on all synchronous entry end exit paths.
Drop the write_cr3 macro, as the two use sites are probably easier to
follow without i
Introduce a synthetic feature flag to use alternative instruction
patching to NOP out all code on entry/exit paths other than those
involved in NMI/#MC handling (the patching logic can't properly handle
those paths yet). Having NOPs here is generally better than using
conditional branches.
Also ch
When XPTI is active, the CR3 load in restore_all_guest is sufficient
when switching to user mode, improving in particular system call and
page fault exit paths for the guest.
Signed-off-by: Jan Beulich
---
v2: Add ASSERT(!in_irq()).
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@
At the same time also report the state of the two defined
ARCH_CAPABILITIES MSR bits. To avoid further complicating the
conditional around that printk(), drop it (it's a debug level one only
anyway).
Signed-off-by: Jan Beulich
---
v2: Re-base over split off earlier patch. Drop MSR_ from
MSR_A
Use the respective ARCH_CAPABILITIES MSR bit, but don't expose the MSR
to guests yet.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -204,6 +204,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
{"avx512-4fmaps",0x0007, 0, CPU
On Wed, Feb 07, 2018 at 08:08:15AM -0700, Jan Beulich wrote:
> I have no idea what *.1 is meant to cover. Instead also exclude
> preprocessed and non-source assembly files.
Oh, I guess that answers my question in 2/4 then. I don't seem to have
neither .i or .a files, but certainly .s should be exc
On Wed, Feb 07, 2018 at 08:08:47AM -0700, Jan Beulich wrote:
> "mkdir -p" reports a missing operand, as config/ has no subdirs. Oddly
> enough this doesn't cause the whole command (and hence the build to
> fail), despite the "set -e" now covering the entire set of commands -
> perhaps a quirk of th
On Wed, Feb 07, 2018 at 08:37:13AM -0700, Jan Beulich wrote:
> >>> On 07.02.18 at 11:53, wrote:
> > docs/misc/coverage.markdown | 2 +-
> > xen/Kconfig.debug| 6 +++---
> > xen/Rules.mk | 9 +++--
> > xen/arch/x86/efi/Makefile| 2 +-
> > xen/common/Makefile
Hi Wei and Julien,
2018-02-07 2:06 GMT+08:00 Wei Liu :
> On Tue, Feb 06, 2018 at 01:24:30PM +, Julien Grall wrote:
>> > if (libxl__device_pci_destroy_all(gc, domid) < 0)
>> > LOGD(ERROR, domid, "Pci shutdown failed");
>> > rc = xc_domain_pause(ctx->xch, domid);
>> > diff
>>> On 07.02.18 at 17:05, wrote:
> On Wed, Feb 07, 2018 at 08:07:40AM -0700, Jan Beulich wrote:
>> I have no idea what *.d1 is supposed to refer to - we only have .*.d
>> and .*.d2 files (note also the leading dot).
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/tools/firmware/xen-dir/Makefile
>>
>>> On 07.02.18 at 17:12, wrote:
> On Wed, Feb 07, 2018 at 08:08:15AM -0700, Jan Beulich wrote:
>> I have no idea what *.1 is meant to cover. Instead also exclude
>> preprocessed and non-source assembly files.
>
> Oh, I guess that answers my question in 2/4 then. I don't seem to have
> neither .i
On 07/02/18 16:27, Zhongze Liu wrote:
Hi Wei and Julien,
Hi,
2018-02-07 2:06 GMT+08:00 Wei Liu :
On Tue, Feb 06, 2018 at 01:24:30PM +, Julien Grall wrote:
if (libxl__device_pci_destroy_all(gc, domid) < 0)
LOGD(ERROR, domid, "Pci shutdown failed");
rc = xc_domain
>>> On 02.02.18 at 09:14, wrote:
> @@ -2313,6 +2314,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
> }
> }
>
> +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */
> +{
> +noflush = !!(value & X86_CR3_NOFLUSH);
Pointless !!.
> --- a/xen/include/a
Signed-off-by: Wei Liu
---
tools/ocaml/libs/xb/xb.mli | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli
index b4d705201f..95d1c6f840 100644
--- a/tools/ocaml/libs/xb/xb.mli
+++ b/tools/ocaml/libs/xb/xb.mli
@@ -76,10 +76
To stay in line with other parts of the ocaml code base.
This requires committing a bunch of mli files in tree.
Signed-off-by: Wei Liu
---
tools/ocaml/libs/xb/Makefile| 4
tools/ocaml/libs/xb/op.mli | 29 +
tools/ocaml/libs/xb/packet.mli | 13
Wei Liu (2):
ocaml/xb: update xb.mli in accordance with df1e4c6e7f8
ocaml/libs/xb: don't generate *.mli automatically
tools/ocaml/libs/xb/Makefile| 4
tools/ocaml/libs/xb/op.mli | 29 +
tools/ocaml/libs/xb/packet.mli | 13 +
tools/ocaml/
On 07/02/18 15:06, Jan Beulich wrote:
On 07.02.18 at 14:24, wrote:
>> On 07/02/18 13:08, Jan Beulich wrote:
>> On 07.02.18 at 14:01, wrote:
So far the issue confirmed:
Dell PowerEdge R740, Huawei systems based on Xeon Gold 6152 (the one
that it was tested on), Intel S2600X
On Wed, Feb 07, 2018 at 04:11:17PM +0100, Olaf Hering wrote:
> Remove the executable bits of vtpm files by using _DATA instead of _PROG.
>
> Signed-off-by: Olaf Hering
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https:
flight 118650 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118650/
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
> On 7. Feb 2018, at 17:09, Wei Liu wrote:
>
> To stay in line with other parts of the ocaml code base.
>
> This requires committing a bunch of mli files in tree.
>
> Signed-off-by: Wei Liu
> ---
> tools/ocaml/libs/xb/Makefile| 4
> tools/ocaml/libs/xb/op.mli | 29 +
> On 7. Feb 2018, at 17:09, Wei Liu wrote:
>
> Signed-off-by: Wei Liu
> ---
> tools/ocaml/libs/xb/xb.mli | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli
> index b4d705201f..95d1c6f840 100644
> --- a/tools/ocam
On 02/07/2018 07:01 PM, Jan Beulich wrote:
On 02.02.18 at 09:14, wrote:
>> @@ -2313,6 +2314,12 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>> }
>> }
>>
>> +if ( hvm_pcid_enabled(v) ) /* Clear the noflush bit. */
>> +{
>> +noflush = !!(value & X86_
Prarit Bhargava:
> A system booted with a small number of cores enabled per package
> panics because the estimate of __max_logical_packages is too low.
> This occurs when the total number of active cores across all packages
> is less than the maximum core count for a single package.
>
> ie) On a 4
flight 118633 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118633/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsmbroken
test-amd6
On 02/07/2018 01:44 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> A system booted with a small number of cores enabled per package
>> panics because the estimate of __max_logical_packages is too low.
>> This occurs when the total number of active cores across all packages
>> is less than the maxi
Prarit Bhargava:
> On 02/07/2018 01:44 PM, Simon Gaiser wrote:
>> Prarit Bhargava:
>>> A system booted with a small number of cores enabled per package
>>> panics because the estimate of __max_logical_packages is too low.
>>> This occurs when the total number of active cores across all packages
>>>
On 02/07/2018 02:26 PM, Simon Gaiser wrote:
> Prarit Bhargava:
>> On 02/07/2018 01:44 PM, Simon Gaiser wrote:
>>> This breaks booting as Xen PV domain for me. The problem seems to be
>>> that native_smp_cpus_done() is never called on a PV domain. So
>>> __max_logical_packages is uninitialized
On 07/02/18 16:12, Jan Beulich wrote:
> I'm not sure why I didn't do this right away: By avoiding the use of
> global PTEs in the cloned directmap, there's no need to fiddle with
> CR4.PGE on any of the entry paths. Only the exit paths need to flush
> global mappings.
>
> The reduced flushing, howe
Hi all,
This is the latest status of the SP2 mitigations for Xen on Arm. Please
note that arm32 and arm64 require different mitigations.
I have just backported the arm32 mitigation to 4.10, 4.9, 4.8 and 4.7:
- 4.10
bbd093c xen/arm32: entry: Document the purpose of r11 in the traps handler
a69a8b
flight 118660 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118660/
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
Commit 82616f9599a7 ("xen: remove tests for pvh mode in pure pv paths")
removed the check for autotranslation from {set,clear}_foreign_p2m_mapping
but those are called by grant-table.c also on PVH/HVM guests.
Cc: # 4.14
Fixes: 82616f9599a7 ("xen: remove tests for pvh mode in pure pv paths")
Signe
Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
Reported-by: Andrew Cooper
Signed-off-by: Brian Woods
---
xen/arch/x86/hvm/svm/svm.c | 71 +
xen/arch/x86/hvm/svm/vmcb.c | 17 ---
2 files changed, 71 insertions(+), 17 d
If Andy wants to use his version of this, that's fine also. This is
just a newer version based on Jan's input.
v1 -> v2
Got rid of "== X"s
Added an assert and got rid of a check in an if
--
Brian Woods
___
Xen-devel mailing list
Xen-devel@lis
Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
concurrent xenstore accesses") made a subtle change to the semantic of
xenbus_dev_request_and_reply() and xenbus_transaction_end().
Before on an error response to XS_TRANSACTION_END
xenbus_dev_request_and_reply() would not decrement th
As the previous commit shows it's quite easy to confuse the transaction
reference counting by ending a transaction twice. So at least try to
detect and report it.
Signed-off-by: Simon Gaiser
---
drivers/xen/xenbus/xenbus_xs.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/x
flight 118665 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118665/
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
The kernel panics on PV domains because native_smp_cpus_done() is
only called for HVM domains.
Calculate __max_logical_packages for PV domains.
Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
Signed-off-by: Prarit Bhargava
Tested-and-reported-by: Simon Gaiser
Cc: Thomas
On 02/07/2018 06:49 PM, Prarit Bhargava wrote:
The kernel panics on PV domains because native_smp_cpus_done() is
only called for HVM domains.
Calculate __max_logical_packages for PV domains.
Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
Signed-off-by: Prarit Bhargav
Applications like libvirt may not populate a device devid field,
delegating that to libxl. If needed, the application can later
retrieve the libxl-produced devid. Indeed most devices are handled
this way in libvirt, channel devices included.
This works well when only one channel device is defined,
flight 118636 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118636/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 broken
test-amd64-i386-freebsd10-amd64 4 host-
1 - 100 of 104 matches
Mail list logo
