Hi,
Maybe this is a silly question but which tag are the 4.10 XPTI
commits from https://xenbits.xen.org/xsa/xsa254/README.pti against?
They don't apply to RELEASE-4.10.0.
Cheers,
Andy
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://li
flight 118167 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118167/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 7 xen-boot fail REGR. vs. 117931
test-amd64-amd6
Roger Pau Monne:
> Previously when trying to boot a PV capable but not PVH capable kernel
> inside of a PVH container xc_dom_guest_type would succeed and return a
> PV guest type, which would lead to failures later on in the build
> process.
>
> Instead provide a clear error message when trying to
On 01/17/2018 12:22 AM, Julien Grall wrote:
Hi Manish,
Hi Julien,
Thanks for reviewing this patch.
On 02/01/18 09:28, manish.ja...@linaro.org wrote:
From: Manish Jaggi
Code to query estimated IORT size for hardware domain.
Please avoid indenting the commit message.
ok.
IORT for h
On 01/17/2018 12:01 AM, Julien Grall wrote:
Hi Manish,
Hi Julien,
Thanks for reviewing the patch.
I sent the previous e-mail too soon.
On 02/01/18 09:27, manish.ja...@linaro.org wrote:
From: Manish Jaggi
Public API to populate and query map between requester id and
streamId/DeviceID.
flight 118171 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118171/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64broken
test-amd64-i386-xl-qemut-de
flight 118219 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118219/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 118165 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118165/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs.
117870
Tests w
On Thu, 18 Jan 2018, Andrew Cooper wrote:
> On 18/01/2018 22:11, Stefano Stabellini wrote:
> > On Tue, 16 Jan 2018, Jan Beulich wrote:
> > On 15.01.18 at 19:51, wrote:
> >>> On Mon, 15 Jan 2018, Jan Beulich wrote:
> >>> On 13.01.18 at 07:21, wrote:
> > On 01/12/2018 11:40 PM, Stefano
Hi Stefano,
On 18 January 2018 at 21:48, Stefano Stabellini wrote:
> r12 and x16 are of different sizes; when passing r12 as a reference to
> do_trap_hypercall on arm64, we end up dereferencing it as a pointer to a
> 64bit value, but actually it isn't.
>
> Instead, use a temporary variable to pas
On 18/01/2018 22:11, Stefano Stabellini wrote:
> On Tue, 16 Jan 2018, Jan Beulich wrote:
> On 15.01.18 at 19:51, wrote:
>>> On Mon, 15 Jan 2018, Jan Beulich wrote:
>>> On 13.01.18 at 07:21, wrote:
> On 01/12/2018 11:40 PM, Stefano Stabellini wrote:
>> handles can theoretically be
On Tue, 16 Jan 2018, Jan Beulich wrote:
> >>> On 15.01.18 at 19:51, wrote:
> > On Mon, 15 Jan 2018, Jan Beulich wrote:
> >> >>> On 13.01.18 at 07:21, wrote:
> >> > On 01/12/2018 11:40 PM, Stefano Stabellini wrote:
> >> >> handles can theoretically be NULL, check for it explicitly before
> >> >> d
On Mon, 15 Jan 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/13/2018 12:29 AM, Stefano Stabellini wrote:
> > lowmem is unchanged until after this loop, there is no point in testing
> > for its value. Moreover, Coverity complains about dead code.
> >
> > Remove the lowmem test in the first loo
r12 and x16 are of different sizes; when passing r12 as a reference to
do_trap_hypercall on arm64, we end up dereferencing it as a pointer to a
64bit value, but actually it isn't.
Instead, use a temporary variable to pass r12, and write back the result
after the call to do_trap_hypercall.
CID: 14
On Thu, 18 Jan 2018, Julien Grall wrote:
> (+ Security team)
>
> Hi Stefano,
>
> On 17/01/18 21:47, Stefano Stabellini wrote:
> > On Wed, 17 Jan 2018, Stefano Stabellini wrote:
> > > On Wed, 17 Jan 2018, Lars Kurth wrote:
> > > >Regarding README.source, this is covering file and contain t
flight 118159 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118159/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 117930
test-amd64-amd64-xl-qemuu-win7-amd6
Hi Manish,
Again please use scripts/get_maintainers.pl.
On 02/01/18 09:28, manish.ja...@linaro.org wrote:
From: Manish Jaggi
This patch adds to_pci_dev macro
Why? Who is going to use it? If it is a patch in your series, then
likely this patch should be before you use it.
Any in case, a c
Hi Manish,
On 02/01/18 09:28, manish.ja...@linaro.org wrote:
From: Manish Jaggi
This patch adds xen specific changes to iort.c
When I see the diff below, it is not changed but fully rewrite.
The original file contains 1279 lines, but you remove 978 lines and add
71. In that context, I see
On Thu, Jan 18, 2018 at 6:19 AM, Razvan Cojocaru
wrote:
> Hello,
>
> We're looking at potentially working with vm_event on SVM hosts. To that
> end, we've removed a few cpu_has_vmx tests and saw that some things just
> work.
>
> That is, unfortunately, not the case for EPT events.
>
> There's this
Hi Manish,
The usual scripts/get_maintainers.pl.
On 02/01/18 09:28, manish.ja...@linaro.org wrote:
From: Manish Jaggi
Add ACPI_IORT config
Singed-off-by: Manish Jaggi
---
xen/arch/arm/Kconfig | 5 +
xen/drivers/acpi/Kconfig | 3 +++
2 files changed, 8 insertions(+)
diff --git
Hi Manish,
Please use scripts/get_maitainers.pl to CC relevant maintainers.
On 02/01/18 09:28, manish.ja...@linaro.org wrote:
From: Manish Jaggi
Add kalloc kfree functions from linux kernel.
This does not description all the functions you added. But I am really
not convinced this is the ri
Hi Manish,
Please use scripts/get_maintainers.pl to CC relevant maintainers. I have
done it for you this time.
Title: s/spacific/specific/
On 02/01/18 09:28, manish.ja...@linaro.org wrote:
From: Manish Jaggi
Merge few more changes from linux kernel code (v4.14) into iommu.c
Modify code sp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-5753,CVE-2017-5715,CVE-2017-5754 / XSA-254
version 10
Information leak via side effects of speculative execution
UPDATES IN VERSION 10
=
Provided summary
Hi,
On 02/01/18 09:28, manish.ja...@linaro.org wrote:
From: Manish Jaggi
First of all, I would expect a commit message explaining roughly the
logic. I am only going to skim through this patch and will wait a proper
description to fully read it.
A general comment, please respect the codin
On 18/01/18 18:28, Wei Liu wrote:
> On Thu, Jan 18, 2018 at 06:26:02PM +, Andrew Cooper wrote:
>> On 18/01/18 18:16, Wei Liu wrote:
>>> To avoid having it changed every time the shim is built.
>>>
>>> Signed-off-by: Wei Liu
>> One downside of having a this config in-tree is that it needs
>> re
On Thu, Jan 18, 2018 at 06:26:02PM +, Andrew Cooper wrote:
> On 18/01/18 18:16, Wei Liu wrote:
> > To avoid having it changed every time the shim is built.
> >
> > Signed-off-by: Wei Liu
>
> One downside of having a this config in-tree is that it needs
> regenerating every time the Kconfig lo
On 18/01/18 18:16, Wei Liu wrote:
> We use the default scheduler (credit1 as of writing). The NULL
> scheduler still has bugs to fix.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https
On 18/01/18 18:16, Wei Liu wrote:
> Remove extraneous semicolon. Add blank lines.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 18/01/18 18:16, Wei Liu wrote:
> To avoid having it changed every time the shim is built.
>
> Signed-off-by: Wei Liu
One downside of having a this config in-tree is that it needs
regenerating every time the Kconfig logic changes.
OTOH, I did deliberately wire up all the config options, so
ma
Modify early boot code to relocate pvh info as well, so that we can be
sure __va in __start_xen works.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/boot/Makefile | 7 +-
xen/arch/x86/boot/build32.mk | 3 +++
xen/arch/x86/boot/defs.h | 3 +++
xen/ar
This reverts commit 7d6f958d9d18c54017f5ef6e299a08037f035747.
Now we have PVH info relocation support, this change is no longer
needed.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/boot/x86_64.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
We use the default scheduler (credit1 as of writing). The NULL
scheduler still has bugs to fix.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Andrew Cooper
---
docs/man/xl.cfg.pod.5.in | 2 +-
tools/libxl/libxl_internal.h | 2 +-
2 files changed, 2 insertions(+), 2 deleti
So that we can have accurate stolen time accounting. Idea taken from
Vixen work from Amazon.
Signed-off-by: Wei Liu
---
Cc: Roger Pau Monné
Cc: Anthony Liguori
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/common/domain.c | 10 ++
xen/include/asm-x86/guest/hypercall.h |
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
tools/libxl/libxl_dom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b03386409f..e1a3e747fc 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -106
According to [0], some program sends NUL for padding purpose. We can
discard them.
https://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html#SEC7
Reported-by: Sarah Newman
Signed-off-by: Wei Liu
---
Cc: Sarah Newman
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
A
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
tools/libxl/libxl_dom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1a3e747fc..b880341d7e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -103
First batch of patches to fix problems I know of.
Wei Liu (9):
Update shim.config
libxl: remove whitespaces introduced in 62982da926
x86/guest: clean up guest/xen.h
Remove sched=null from shim cmdline and doc
x86: relocate pvh_info
Revert "x86/boot: Map more than the first 16MB"
libx
To avoid having it changed every time the shim is built.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
tools/firmware/xen-dir/shim.config | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/firmware/xen-dir/shim.config
b/tools/firmware/xen-dir/shim.config
index 78b965f
Remove extraneous semicolon. Add blank lines.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/include/asm-x86/guest/xen.h | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/include/asm-x86/guest/xen.h b/xen/include/asm-x86/guest/xen.h
inde
On 01/18/2018 10:46 AM, Andrew Cooper wrote:
> For performance reasons, HVM guests should have direct access to these MSRs
> when possible.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Jun Nakajima
> CC: Kevin Tian
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
>
> v7:
>
flight 118154 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118154/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw broken
test-armhf-armhf-libv
On 18/01/18 17:04, Doug Goldstein wrote:
> Allow a user to supply extra CFLAGS via the EXTRA_CFLAGS environment
> variable. This is not a configuration that is supported but is only
> aimed to help support testing and troubleshooting when you need to make
> changes.
>
> Signed-off-by: Doug Goldste
Hi,
On 18/01/18 17:25, Manish Jaggi wrote:
On 01/18/2018 10:22 PM, Julien Grall wrote:
Hi Manish,
Hi Julien,
On 18/01/18 06:15, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
This patch introduces a function vgic_map_translation_space for mapping
ITS 64K translater space for doorbe
On 01/18/2018 10:22 PM, Julien Grall wrote:
Hi Manish,
Hi Julien,
On 18/01/18 06:15, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
This patch introduces a function vgic_map_translation_space for mapping
ITS 64K translater space for doorbells in dom0 stage-2.
It is required as dom0 P
flight 118166 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118166/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 117116
test-armhf-armhf-libvirt-raw 13 s
Doug Goldstein writes ("[PATCH] xen: append EXTRA_CFLAGS to CFLAGS for expert
builds"):
> Allow a user to supply extra CFLAGS via the EXTRA_CFLAGS environment
> variable. This is not a configuration that is supported but is only
> aimed to help support testing and troubleshooting when you need to
Allow a user to supply extra CFLAGS via the EXTRA_CFLAGS environment
variable. This is not a configuration that is supported but is only
aimed to help support testing and troubleshooting when you need to make
changes.
Signed-off-by: Doug Goldstein
---
CC: Andrew Cooper
CC: George Dunlap
CC: Ia
Hi Manish,
On 18/01/18 06:15, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
This patch introduces a function vgic_map_translation_space for mapping
ITS 64K translater space for doorbells in dom0 stage-2.
It is required as dom0 PCI devices behined SMMU wont be able to write MSIs.
s/beh
flight 118153 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118153/
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. 118112
test-amd64-amd64-xl-
Hi Jan,
On 18/01/18 15:59, Jan Beulich wrote:
On 20.12.17 at 10:34, wrote:
p2m_pod_decrease_reservation() at the moment only returns a boolean
value: true for "nothing more to do", false for "something more to do".
If it returns false, decrease_reservation() will loop over the entire
range, ca
It appears there is a case where Windows enables the APIC assist
enlightenment[1] but does not use it. This scenario is perfectly valid
according to the documentation, but causes the state machine in Xen to
become confused leading to a domain_crash() such as the following:
(XEN) d4: VIRIDIAN GUEST
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 January 2018 16:21
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2] x86/hvm: re-work viridian APIC assist code
>
> >>> On 18.01.18 at 16:10, wrote:
> > -int
>>> On 18.01.18 at 16:10, wrote:
> -int viridian_complete_apic_assist(struct vcpu *v)
> +bool viridian_apic_assist_completed(struct vcpu *v)
> {
> uint32_t *va = v->arch.hvm_vcpu.viridian.vp_assist.va;
> -int vector;
>
> if ( !va )
> -return 0;
> +return false;
>
On 1/17/18 6:56 AM, Roger Pau Monne wrote:
> When using a linker that supports both formats the following error
> will be triggered:
>
> efi/buildid.o: file not recognized: File format is ambiguous
> efi/buildid.o: matching formats: coff-x86-64 pe-x86-64
>
> Solve this by specifying the efi/build
>>> On 18.01.18 at 16:46, wrote:
> This is a rebasing error in c/s 858cba0d4c6b "x86: Introduce alternative
> indirect thunks" hidden by other changes in the same sentence.
>
> The name with dots rather than underscores was the prerelease GCC ABI.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan
>>> On 20.12.17 at 10:34, wrote:
> p2m_pod_decrease_reservation() at the moment only returns a boolean
> value: true for "nothing more to do", false for "something more to do".
> If it returns false, decrease_reservation() will loop over the entire
> range, calling guest_remove_page() for each pag
With all infrastructure in place, it is now safe to let guests see and use
these features.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Acked-by: Wei Liu
---
v9:
* Split patch in half with the libxc hunk moving earlier, and rebasing over
the changed nature of STIBP
---
xen/include/pu
On contemporary hardware, setting IBRS/STIBP has a performance impact on
adjacent hyperthreads. It is therefore recommended to clear the setting
before becoming idle, to avoid an idle core preventing adjacent userspace
execution from running at full performance.
Care must be taken to ensure there
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
---
xen/arch/x86/domctl.c | 2 ++
xen/arch/x86/hvm/hvm.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 2585d4e..1a15a34 100644
--- a/xen/arch/x86/domctl.c
+++
We need to be able to either set or clear IBRS in Xen context, as well as
restore appropriate guest values in guest context. See the documentation in
asm-x86/spec_ctrl_asm.h for details.
Writes to %cr3 are slower when SPEC_CTRL.IBRS is set, so the
SPEC_CTRL_{ENTRY/EXIT}* positioning is important,
For performance reasons, HVM guests should have direct access to these MSRs
when possible.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
v7:
* Drop excess brackets
v9:
* Re-implement it light of Intels new sp
Issuing an IBPB command flushes the Branch Target Buffer, so that any poison
left by one vcpu won't remain when beginning to execute the next.
The cost of IBPB is substantial, and skipped on transition to idle, as Xen's
idle code is robust already. All transitions into vcpu context are fully
seri
Intel specifies IBRS/IBPB (combined, in a single bit) and STIBP as a separate
bit. AMD specifies IBPB alone in a 3rd bit.
AMD's IBPB is a subset of Intel's combined IBRS/IBPB. For performance
reasons, administrators might wish to express "IBPB only" even on Intel
hardware, so we allow the AMD bi
ret instructions are speculated directly to values recorded in the RSB/RAS, as
there is no uncertainty in well-formed code. Guests can take advantage of
this in two ways:
1) If they can find a path in Xen which executes more ret instructions than
call instructions. (At least one in the wa
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v7:
* static, and tweak comment
---
docs/misc/xen-command-line.markdown | 6 ++-
xen/arch/x86/spec_ctrl.c| 104 ++--
2 files changed, 105 insertions(+), 5 deletions(-)
diff --git a/docs/misc/xen-com
This is a rebasing error in c/s 858cba0d4c6b "x86: Introduce alternative
indirect thunks" hidden by other changes in the same sentence.
The name with dots rather than underscores was the prerelease GCC ABI.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v9: New.
---
xen/arch/x86/indirect-th
As per the spec currently available here:
https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
MSR_ARCH_CAPABILITIES will only come into existence on new hardware, but is
implemented as a straight #GP for now to avoid being leaky w
This series is availabe in git form from:
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/sp2-mitigations-v9
A copy of Intel's spec for IBRS/IBPB can be found here:
https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-
I'm not sure why I didn't do this right away: By avoiding to make any
of the cloned directmap PTEs global, 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
It appears there is a case where Windows enables the APIC assist
enlightenment[1] but does not use it. This scenario is perfectly valid
according to the documentation, but causes the state machine in Xen to
become confused leading to a domain_crash() such as the following:
(XEN) d4: VIRIDIAN GUEST
Hi, Roger
On Thu, Jan 18, 2018 at 2:09 PM, Roger Pau Monné wrote:
> Sorry for the delay in the reply.
No problem.
>
> On Tue, Jul 25, 2017 at 08:26:49PM +0300, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> The hardware domains require IOMMU to be used in the most cases and
>>
>>> On 03.01.18 at 09:26, wrote:
> The previous aes insns only support legacy and AVX128.
> Icelake added AVX256 support.
Same remark here as for the pclmulqdq patch.
> Signed-off-by: Yang Zhong
> ---
Please provide a brief list of changes at this spot in each patch.
> @@ -7336,17 +7337,23 @@
>>> On 03.01.18 at 09:26, wrote:
> The previous vpclmulqdq only support AVX128.
> Icelake added AVX256 support.
And 512-bit support as well; you only don't add support for the EVEX
encoding forms in your patch.
The patch itself looks fine, but please clarify its testing status.
> @@ -6168,6 +61
flight 118210 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118210/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
This looks good to me. I don't think conditional compilation can be avoided
here.
-- Christian
> On 17. Jan 2018, at 17:00, Wei Liu wrote:
>
> CC Ocaml experts
>
> On Wed, Jan 17, 2018 at 04:43:54PM +, Wei Liu wrote:
>> ARM doesn't have emulation_flags in the arch_domainconfig.
>>
>> Sig
Hello,
We're looking at potentially working with vm_event on SVM hosts. To that
end, we've removed a few cpu_has_vmx tests and saw that some things just
work.
That is, unfortunately, not the case for EPT events.
There's this old thread about NPT support:
https://lists.gt.net/xen/devel/339571
b
>>> On 18.01.18 at 12:21, wrote:
> Actually reading through the code and the spec. again, I'm not convinced by
> the logic even with the EOI fix. It looks to me like vlapic_has_pending_irq()
> could leave an existing assist in place and return a higher priority irr
> value. This guest would the
(+ Security team)
Hi Stefano,
On 17/01/18 21:47, Stefano Stabellini wrote:
On Wed, 17 Jan 2018, Stefano Stabellini wrote:
On Wed, 17 Jan 2018, Lars Kurth wrote:
Regarding README.source, this is covering file and contain the same
mention as in the commit message. As this is a single fu
Sorry for the delay in the reply.
On Tue, Jul 25, 2017 at 08:26:49PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> The hardware domains require IOMMU to be used in the most cases and
> a decision to use it is made at hardware domain construction time.
> But, it is not the b
On Wed, Jan 17, 2018 at 10:39:01AM -0600, Eric DeVolder wrote:
> When kexec is utilized in a Xen environment, it has an explicit
> run-time dependency on libxenctrl.so. This dependency occurs
> during the configure stage and when building kexec-tools.
[...]
As I saw Simon applied the patch. Great
Hi Stefano,
On 17/01/18 18:26, Stefano Stabellini wrote:
On Tue, 16 Jan 2018, Julien Grall wrote:
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 7de68361ff..23ebf367ea 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -1,
flight 118206 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118206/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 118105
Tests which
On Thu, Jan 18, 2018 at 11:31:51AM +, Wei Liu wrote:
> On Thu, Jan 18, 2018 at 11:10:50AM +, Wei Liu wrote:
> > On Tue, Jan 09, 2018 at 08:31:52AM +0800, Yi Sun wrote:
> > > On 18-01-08 12:25:02, Wei Liu wrote:
> > > > On Mon, Jan 08, 2018 at 12:28:58PM +0800, Yi Sun wrote:
> > > > > On 17-
>>> On 18.01.18 at 12:00, wrote:
> On 18/01/18 10:57, Andrew Cooper wrote:
>> On 18/01/18 10:38, George Dunlap wrote:
>>> On Thu, Jan 18, 2018 at 7:59 AM, Jan Beulich wrote:
>>> On 12.01.18 at 19:37, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1942,11
On Thu, Jan 18, 2018 at 11:10:50AM +, Wei Liu wrote:
> On Tue, Jan 09, 2018 at 08:31:52AM +0800, Yi Sun wrote:
> > On 18-01-08 12:25:02, Wei Liu wrote:
> > > On Mon, Jan 08, 2018 at 12:28:58PM +0800, Yi Sun wrote:
> > > > On 17-12-20 02:11:32, Jan Beulich wrote:
> > > > > >>> On 19.12.17 at 01:
On Thu, Jan 18, 2018 at 04:22:11AM -0700, Jan Beulich wrote:
> >>> On 18.01.18 at 12:11, wrote:
> > Jan Beulich writes ("Re: [PATCH v2 3/6] xen/pvshim: identity pin shim vCPUs
> > to pCPUs"):
> >> On 17.01.18 at 17:29, wrote:
> >> > Since VCPUOP_{up/down} already identity maps vCPU hotplug to pC
>>> On 18.01.18 at 12:11, wrote:
> Jan Beulich writes ("Re: [PATCH v2 3/6] xen/pvshim: identity pin shim vCPUs
> to pCPUs"):
>> On 17.01.18 at 17:29, wrote:
>> > Since VCPUOP_{up/down} already identity maps vCPU hotplug to pCPU
>> > hotplug also identity pin the vCPUs to the pCPUs in the schedul
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 18 January 2018 10:37
> To: 'Jan Beulich'
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is
Hi,
On 17/01/18 17:11, Stefano Stabellini wrote:
On Wed, 17 Jan 2018, Julien Grall wrote:
Hi Stefano,
On 17/01/18 00:42, Stefano Stabellini wrote:
On Tue, 16 Jan 2018, Julien Grall wrote:
#define MIDR_RANGE(model, min, max) \
@@ -205,6 +232,28 @@ static const struct arm_cpu_capabiliti
On Thu, Jan 18, 2018 at 11:02:51AM +, Roger Pau Monne wrote:
> The -printf find option is not POSIX compatible, so replace it with
> another rune.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xe
Roger Pau Monne writes ("[PATCH v3 6/7] firmware/shim: fix build process to use
POSIX find options"):
> The -printf find option is not POSIX compatible, so replace it with
> another rune.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@list
On Thu, Jan 18, 2018 at 11:02:52AM +, Roger Pau Monne wrote:
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
> Requested-by: Andrew Cooper
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https:/
Jan Beulich writes ("Re: [PATCH v2 3/6] xen/pvshim: identity pin shim vCPUs to
pCPUs"):
> On 17.01.18 at 17:29, wrote:
> > Since VCPUOP_{up/down} already identity maps vCPU hotplug to pCPU
> > hotplug also identity pin the vCPUs to the pCPUs in the scheduler.
> > This prevents vCPU migration and
Roger Pau Monné writes ("Re: [Xen-devel] [PATCH 6/6] firmware/shim: fix build
process to use POSIX find options"):
> What about using:
>
> find $(XEN_ROOT)/$(d)/ -type d | sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir
> -p
>
> This AFAICT works fine, and should be the one involving less forks
> s
On Tue, Jan 09, 2018 at 08:31:52AM +0800, Yi Sun wrote:
> On 18-01-08 12:25:02, Wei Liu wrote:
> > On Mon, Jan 08, 2018 at 12:28:58PM +0800, Yi Sun wrote:
> > > On 17-12-20 02:11:32, Jan Beulich wrote:
> > > > >>> On 19.12.17 at 01:42, wrote:
> > > > > We plan to bring a new PSR (Platform Shared R
On Thu, Jan 18, 2018 at 10:44:58AM +, Wei Liu wrote:
> On Wed, Jan 17, 2018 at 04:43:54PM +, Wei Liu wrote:
> > ARM doesn't have emulation_flags in the arch_domainconfig.
> >
> > Signed-off-by: Wei Liu
> > ---
> > Cc: Ian Jackson
> > Cc: Julien Grall
> > Cc: Andrew Cooper
> > ---
> >
No functional change.
Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
Changes since v1:
- Fix double ; and space.
---
xen/arch/x86/pv/shim.c | 21 ++---
1 file changed, 6 insertions(+), 15 deletions(-)
diff
On 18/01/18 11:02, Roger Pau Monne wrote:
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
> Requested-by: Andrew Cooper
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Wei Liu
Acked-by: Andrew Cooper
Thanks.
___
Xen-devel ma
Fix a couple of coding style issues.
No code or functional change.
Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/pv/shim.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git
Since VCPUOP_{up/down} already identity maps vCPU hotplug to pCPU
hotplug also identity pin the vCPUs to the pCPUs in the scheduler.
This prevents vCPU migration and should improve performance.
While there also use __cpumask_set_cpu instead of cpumask_set_cpu,
there's no need to use the locked var
1 - 100 of 135 matches
Mail list logo
