Sorry for the noise, it looks description is wrong.
This is not a double pop, but xen pv taking the path
with create_gap=0, I'll send a v2.
Zhenzhong
On 2019/7/11 12:47, Zhenzhong Duan wrote:
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") reveals a bug in XEN PV in
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup in exception stack
which could be used for inserting call return address.
This gap is missed in XEN PV int3 exception entry path, then below panic
triggered:
[0.772876] general pr
flight 138898 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138898/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-build fail in 138772 REGR. vs. 132889
build-amd64-pre
On 7/11/19 14:34, Jan Beulich wrote:
> On 10.07.2019 14:54, Norbert Manthey wrote:
>> Guests can issue grant table operations and provide guest controlled
>> data to them. This data is used as index for memory loads after bound
>> checks have been done. To avoid speculative out-of-bound accesses, w
Dear all,
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative out-o
Guests can issue grant table operations and provide guest controlled
data to them. This data is used as index for memory loads after bound
checks have been done. To avoid speculative out-of-bound accesses, we
use the array_index_nospec macro where applicable, or the macro
block_speculation. Note, t
Guests can issue grant table operations and provide guest controlled
data to them. This data is used as index for memory loads after bound
checks have been done. Depending on the grant table version, the
size of elements in containers differ. As the base data structure is
a page, the number of elem
Hi,
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking, etc)
we want to disable PV extensions. We have xen_nopv for that purpose
but only f
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. We have "xen_nopv" for that purpose
but only for XEN.
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch report warning, so move variable declarations from
hypervisor.c to hypervisor.h
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Bori
.. as they are only called at early bootup stage. In fact, other
functions in x86_hyper_xen_hvm.init.* are all marked as __init.
Unexport xen_hvm_need_lapic as it's never used outside.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
Cc: Boris Ostrovsky
Cc: Stefano Stabellini
Cc: Thom
Clean up unnecessory code after that operation.
Signed-off-by: Zhenzhong Duan
Reviewed-by: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
---
Documentation/admin-guide/kernel-parameters.txt | 2 ++
arch/x86/xen/enlighten_hv
On Thu, Jul 11, 2019 at 04:15:21PM +0800, Zhenzhong Duan wrote:
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 4722ba2..2138d69 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -596,7 +596,7 @@ struct trap_array_entry {
>
> sta
PVH guest needs PV extentions to work, so "nopv" parameter should be
ignored for PVH but not for HVM guest.
If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
we know it's PVH guest and ignore "nopv" parameter directly.
If PVH guest boots up via the normal boot entry same as
On 2019/7/12 20:06, Peter Zijlstra wrote:
On Thu, Jul 11, 2019 at 04:15:21PM +0800, Zhenzhong Duan wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4722ba2..2138d69 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -596,7 +596,7 @@
On Fri, Jul 12, 2019 at 09:04:22PM +0800, Zhenzhong Duan wrote:
>
> On 2019/7/12 20:06, Peter Zijlstra wrote:
> > On Thu, Jul 11, 2019 at 04:15:21PM +0800, Zhenzhong Duan wrote:
> > > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> > > index 4722ba2..2138d69 100644
> > > -
On Fri, Jul 12, 2019 at 03:09:16PM +0200, Peter Zijlstra wrote:
> On Fri, Jul 12, 2019 at 09:04:22PM +0800, Zhenzhong Duan wrote:
> >
> > On 2019/7/12 20:06, Peter Zijlstra wrote:
> > > On Thu, Jul 11, 2019 at 04:15:21PM +0800, Zhenzhong Duan wrote:
> > > > diff --git a/arch/x86/xen/enlighten_pv.c
On 2019/7/12 21:09, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 09:04:22PM +0800, Zhenzhong Duan wrote:
On 2019/7/12 20:06, Peter Zijlstra wrote:
On Thu, Jul 11, 2019 at 04:15:21PM +0800, Zhenzhong Duan wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4722b
On 11/07/2019 03:15, Zhenzhong Duan wrote:
> Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
> selftest") is used to ensure there is a gap setup in exception stack
> which could be used for inserting call return address.
>
> This gap is missed in XEN PV int3 exception entry path, th
On 7/11/19 7:29 PM, Denis Obrezkov wrote:
Hi,
Hi,
On 7/11/19 7:32 PM, Julien Grall wrote:
What do you think?
Have you looked at the series I pointed out earlier on? It extends Xen
to support other interrupt controller parent.
Yes, but you said once that these patch series wasn't accept
Hi,
On 7/11/19 7:29 PM, Hunyue Yau wrote:
[This mail incorporates comments raised on IRC. I have made some of this mHi,ore
verbose to provide context to people that haven't seen the IRC comments.]
Thank you for the summary!
This will be a bunch of facts on the am5. Someone else will have re
flight 138902 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138902/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-xl-
flight 138903 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138903/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 138376
build-i386-pre
On 7/11/19 6:59 PM, Martin K. Petersen wrote:
> Hi Chaitanya,
>
>> +static inline sector_t bdev_nr_sects(struct block_device *bdev)
>> +{
>> +return part_nr_sects_read(bdev->bd_part);
>> +}
> Can bdev end up being NULL in any of the call sites?
>
> Otherwise no objections.
>
Thanks for mentioni
Stefano,
I made some notes from our informal design session about adding domB
feature stuff to dom0less, and dom0less on x86
* On x86, envisaging that boot VM start materials (kernel, initrd, etc)
are loaded by multiboot, as extra blobs in the same fashion as the dom0 kernel
and initrd (and e
On Friday, July 12, 2019 16:13:32 Julien Grall wrote:
> Hi,
>
> On 7/11/19 7:29 PM, Hunyue Yau wrote:
> > [This mail incorporates comments raised on IRC. I have made some of this
> > mHi,ore verbose to provide context to people that haven't seen the IRC
> > comments.]
> Thank you for the summary!
flight 138905 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138905/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
test-amd64-i386-xl-qemuu-
Here are the photos I took of the flipchart:
https://xenbits.xen.org/people/iwj/2019/summit-ci-branch-workshop/
My notes, in fairly unredacted form, are below. We should to write
this up into a proper proposal.
-8<-
Phase 1
A robot will create a Gitlab MR out of each of certain branches on
flight 138909 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138909/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
129313
build-armhf-
flight 138912 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138912/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 11 guest-startfail REGR. vs. 138876
test-amd64-i386-libvirt
flight 138914 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138914/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 91cc60bafc7d6e49b7bc85990f895d6228f51364
baseline version:
ovmf 8df52631e53c73cbe5ef0
flight 138911 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138911/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore.2 fail
REGR. vs. 138890
te
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvhv2-intel
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tre
flight 138915 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138915/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 138868
Tests which did no
34 matches
Mail list logo
