[Xen-devel] [linux-3.18 test] 111069: regressions - trouble: blocked/broken/fail/pass

flight 111069 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/111069/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 5 host-build-prep fail REGR. vs. 110441

[Xen-devel] [libvirt test] 111061: tolerable all pass - PUSHED

flight 111061 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/111061/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 111029 test-armhf-armhf-libvirt-xsm 14

[Xen-devel] [xen-4.8-testing baseline-only test] 71601: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71601 xen-4.8-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71601/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumprun-i386 16

[Xen-devel] [linux-4.9 test] 111054: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 111054 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/111054/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-xsm 16 guest-start/debian.repeat fail in 111027 pass in 111054 test-amd64-i386-rumprun-i386

[Xen-devel] [ovmf baseline-only test] 71602: tolerable FAIL

This run is configured for baseline tests only. flight 71602 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71602/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-i386-libvirt5 libvirt-build

[Xen-devel] [linux-linus test] 111053: regressions - trouble: broken/fail/pass

flight 111053 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/111053/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 4 host-install broken REGR. vs. 110515

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

Thank you for the information and feedback. The scenarios to handle are: 1. QEMU emulation 2. blkback. 3. qdisk. >From the previous e-mails, there is an agreement that no functionality (or maybe minimal) should be added to blkback. @Roger Pau Monné: Yes, "drive-mirror" feature handles disks that

[Xen-devel] [ovmf test] 111076: regressions - FAIL

flight 111076 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111076/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 111067

[Xen-devel] [xen-4.6-testing baseline-only test] 71600: regressions - trouble: broken/fail/pass

This run is configured for baseline tests only. flight 71600 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71600/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 19

Re: [Xen-devel] clean up and modularize arch dma_mapping interface V2

On 06/26/2017 02:47 AM, Christoph Hellwig wrote: On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote: I think we still need to do it. For example we have a bunch new "funky" cases. I have no plan to do away with the selection - I just want a better interface than the

[Xen-devel] [xtf test] 111074: all pass - PUSHED

flight 111074 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111074/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 6723a66fe3e2a60793ec4fdbcd67250c954fe5d9 baseline version: xtf

[Xen-devel] [xen-4.9-testing test] 111051: trouble: broken/fail/pass

flight 111051 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/111051/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl-xsm3 host-install(3) broken in 111022 REGR. vs.

Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

On Mon, Jun 26, 2017 at 07:29:22PM +0100, Julien Grall wrote: > Hi, > > On 06/26/2017 04:36 PM, Ross Lagerwall wrote: > > Xen Live Patching has been available as tech preview feature since Xen > > 4.7 and has now had a couple of releases to stabilize. Xen Live patching > > has been used by

Re: [Xen-devel] [PATCH] x86/mm: Fix infinite loop in get_spage_pages()

>>> Andrew Cooper 06/26/17 1:59 PM >>> >c/s 2b8eb37 switched int i to being unsigned, but the undo logic on failure >relied in i being signed. As i being unsigned in still preforable, adjust the >undo logic to work with an unsigned i. > >Coverity-ID: 1413017

Re: [Xen-devel] [PATCH] xen/disk: don't leak stack data via response ring

On Mon, 26 Jun 2017, Jan Beulich wrote: > >>> Stefano Stabellini 06/23/17 8:43 PM >>> > >On Fri, 23 Jun 2017, Jan Beulich wrote: > >> >>> On 22.06.17 at 20:52, wrote: > >> > I am happy to write the code and/or the commit message. Would a simple >

Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

Hi, On 06/26/2017 04:36 PM, Ross Lagerwall wrote: Xen Live Patching has been available as tech preview feature since Xen 4.7 and has now had a couple of releases to stabilize. Xen Live patching has been used by multiple vendors to fix several real-world security issues without any severe bugs

[Xen-devel] q35 support in Xen

I would like to inquire about q35 support in Xen? As far as I have been able to tell, this has not been done? In the Xen version that I've been working with (4.4), libxl_dm overrides any "-machine" argument I try to pass to QEMU with "-machine xenfv". (it appears this still existing in the

[Xen-devel] [qemu-upstream-4.5-testing test] 111047: regressions - FAIL

flight 111047 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/111047/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail REGR. vs. 106846

Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

On 26/06/17 18:00, George Dunlap wrote: > On 26/06/17 16:36, Ross Lagerwall wrote: >> Xen Live Patching has been available as tech preview feature since Xen >> 4.7 and has now had a couple of releases to stabilize. Xen Live patching >> has been used by multiple vendors to fix several real-world

[Xen-devel] [qemu-upstream-4.8-testing test] 111049: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 111049 qemu-upstream-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/111049/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl

Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

On 26/06/17 17:50, George Dunlap wrote: > On 26/06/17 17:39, Andrew Cooper wrote: >>> * Bugs which allow a guest to prevent the application of a livepatch: >>> A guest should not be able to prevent the application of a live >>> patch. If an unprivileged guest can prevent the application of

Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

On 26/06/17 17:50, Ross Lagerwall wrote: > On 06/26/2017 05:39 PM, Andrew Cooper wrote: >> On 26/06/17 16:36, Ross Lagerwall wrote: >> >>> >>> * Bugs which allow a guest to prevent the application of a livepatch: >>> A guest should not be able to prevent the application of a live >>>

Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

On 26/06/17 16:36, Ross Lagerwall wrote: > Xen Live Patching has been available as tech preview feature since Xen > 4.7 and has now had a couple of releases to stabilize. Xen Live patching > has been used by multiple vendors to fix several real-world security > issues without any severe bugs

Re: [Xen-devel] [PATCH v5 06/13] x86: simplify guest_has_trap_callback

On 26/06/17 17:28, Wei Liu wrote: > There is only one caller for that function. Simplify the function, > move it close to the caller and rename it. > > Signed-off-by: Wei Liu Good improvement. In principle, Reviewed-by: Andrew Cooper , although...

Re: [Xen-devel] [PATCH v5 05/13] x86: remove the now empty x86_64/compat/traps.c

On 26/06/17 17:28, Wei Liu wrote: > Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 04/13] x86: move compat_set_trap_table along side the non-compat variant

On 26/06/17 17:28, Wei Liu wrote: > Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 03/13] x86: move do_set_trap_table to pv/callback.c

On 26/06/17 17:28, Wei Liu wrote: > That hypercall is used to set guest callbacks for traps. > > Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

George Dunlap writes ("Re: [PATCH for-4.9] livepatch: Declare live patching as a supported feature"): > I agree that as long as the patch can be applied after "xl pause", then > the domain cannot be said to be preventing the application of the > livepatch. But if either 'xl pause' doesn't work,

Re: [Xen-devel] [PATCH v5 02/13] x86: move the compat callback ops next to the non-compat variant

On 26/06/17 17:28, Wei Liu wrote: > Take the chance to change v to curr. > > Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

On 06/26/2017 05:39 PM, Andrew Cooper wrote: On 26/06/17 16:36, Ross Lagerwall wrote: snip * Unprivileged access to live patching operations: Live patching operations should only be accessible to privileged guests and it shall be treated as a security issue if this is not the

Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

On 26/06/17 17:39, Andrew Cooper wrote: >> * Bugs which allow a guest to prevent the application of a livepatch: >> A guest should not be able to prevent the application of a live >> patch. If an unprivileged guest can prevent the application of a >> live patch, it shall be treated as

[Xen-devel] [PATCH v5 13/13] x86/traps.h: remove unused declaration of cpu_user_regs

Signed-off-by: Wei Liu --- xen/include/asm-x86/traps.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/xen/include/asm-x86/traps.h b/xen/include/asm-x86/traps.h index 8d903ec91b..bed25290d7 100644 --- a/xen/include/asm-x86/traps.h +++ b/xen/include/asm-x86/traps.h @@

[Xen-devel] [PATCH v5 12/13] x86/traps: move some PV specific functions to pv/traps.c

Those functions must be moved at the same time. Also move softirq_trap because it is only used there. Fix some coding style issues while moving code. Signed-off-by: Wei Liu --- xen/arch/x86/pv/traps.c | 104

[Xen-devel] [PATCH v5 10/13] x86/traps: move {un, }register_guest_nmi_callback to pv/callback.c

Move these helper functions along side their users. Now all users of these functions are within the same file, make them static. Take the chance to change v to curr and remove some unneeded parentheses. Signed-off-by: Wei Liu --- xen/arch/x86/pv/callback.c | 37

[Xen-devel] [PATCH v5 11/13] x86/callback.c: slightly change {un, }register_guest_nmi_callback

Make register_guest_nmi_callback return int and make unregister_guest_nmi_callback void. Adjust the callers where necessary. Signed-off-by: Wei Liu --- Can be squashed into previous patch. --- xen/arch/x86/pv/callback.c | 18 ++ 1 file changed, 10

[Xen-devel] [xen-unstable-smoke test] 111075: tolerable trouble: broken/pass - PUSHED

flight 111075 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/111075/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 13

Re: [Xen-devel] [PATCH v5 01/13] x86: move callback_op code to pv/callback.c

On 26/06/17 17:28, Wei Liu wrote: > Take the chance to change v to curr. > > Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

On 26/06/17 16:36, Ross Lagerwall wrote: > Xen Live Patching has been available as tech preview feature since Xen > 4.7 and has now had a couple of releases to stabilize. Xen Live patching > has been used by multiple vendors to fix several real-world security > issues without any severe bugs

[Xen-devel] [PATCH] xen/x86: Don't BUG on CPU0 offlining

CONFIG_BOOTPARAM_HOTPLUG_CPU0 allows to offline CPU0 but Xen HVM guests BUG() in xen_teardown_timer(). Remove the BUG_ON(), this is probably a leftover from ancient times when CPU0 hotplug was impossible, it works just fine for HVM. Signed-off-by: Vitaly Kuznetsov --- - CPU0

Re: [Xen-devel] [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place

On 6/26/2017 10:45 AM, Borislav Petkov wrote: On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote: Normally the __p4d() macro would be used and that would be ok whether CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the paravirt ops path I have to use

[Xen-devel] [PATCH v5 07/13] x86/traps: simplify and rename send_guest_trap

Rename it to pv_raise_interrupt. Simplify the code by using the vcpu structure already at hand in the caller. Signed-off-by: Wei Liu --- xen/arch/x86/traps.c | 13 - xen/include/asm-x86/pv/traps.h | 8 xen/include/asm-x86/traps.h| 9

[Xen-devel] [PATCH v5 06/13] x86: simplify guest_has_trap_callback

There is only one caller for that function. Simplify the function, move it close to the caller and rename it. Signed-off-by: Wei Liu --- xen/arch/x86/cpu/mcheck/vmce.c | 11 ++- xen/arch/x86/traps.c | 18 -- xen/include/asm-x86/traps.h|

[Xen-devel] [PATCH v5 00/13] x86: refactor trap handling code

This series can also be found on my xenbits/xen.git wip.move-traps-v5 Wei Liu (13): x86: move callback_op code to pv/callback.c x86: move the compat callback ops next to the non-compat variant x86: move do_set_trap_table to pv/callback.c x86: move compat_set_trap_table along side the

[Xen-devel] [PATCH v5 02/13] x86: move the compat callback ops next to the non-compat variant

Take the chance to change v to curr. Signed-off-by: Wei Liu --- xen/arch/x86/pv/callback.c | 142 xen/arch/x86/x86_64/compat/traps.c | 143 - 2 files changed, 142 insertions(+), 143

[Xen-devel] [PATCH v5 03/13] x86: move do_set_trap_table to pv/callback.c

That hypercall is used to set guest callbacks for traps. Signed-off-by: Wei Liu --- xen/arch/x86/pv/callback.c | 50 ++ xen/arch/x86/traps.c | 50 -- 2 files changed, 50

[Xen-devel] [PATCH v5 04/13] x86: move compat_set_trap_table along side the non-compat variant

Signed-off-by: Wei Liu --- xen/arch/x86/pv/callback.c | 47 ++ xen/arch/x86/x86_64/compat/traps.c | 44 --- 2 files changed, 47 insertions(+), 44 deletions(-) diff --git a/xen/arch/x86/pv/callback.c

[Xen-devel] [PATCH v5 09/13] xen: move do_nmi_op and make it x86 only

Since ARM doesn't need do_nmi_op, move the hypercall handler from common/kernel.c to pv/callback.c. Drop the stubs in ARM. Delete the common and ARM nmi.h and adjust header inclusions in various files. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew

[Xen-devel] [PATCH v5 01/13] x86: move callback_op code to pv/callback.c

Take the chance to change v to curr. Signed-off-by: Wei Liu --- xen/arch/x86/pv/Makefile| 1 + xen/arch/x86/pv/callback.c | 183 xen/arch/x86/x86_64/traps.c | 148 --- 3 files changed, 184

[Xen-devel] [PATCH v5 05/13] x86: remove the now empty x86_64/compat/traps.c

Signed-off-by: Wei Liu --- xen/arch/x86/x86_64/compat/traps.c | 15 --- xen/arch/x86/x86_64/traps.c| 2 -- 2 files changed, 17 deletions(-) delete mode 100644 xen/arch/x86/x86_64/compat/traps.c diff --git a/xen/arch/x86/x86_64/compat/traps.c

[Xen-devel] [PATCH v5 08/13] x86/traps: factor out pv_trap_init

Factor out pv_trap_init and call it at the beginning of trap_init. We then need to tune the code to generate stub handlers in entry.S. Take the chance to tune init_irq_data so that 0x80 and 0x82 can be used in !CONFIG_PV case. While at it, fix some coding style issues in init_irq_data and replace

Re: [Xen-devel] [PATCH] common/vm_event: Initialize vm_event lists on domain creation

On Mon, Jun 26, 2017 at 9:09 AM, Andrew Cooper wrote: > On 26/06/17 15:52, Tamas K Lengyel wrote: >> On Mon, Jun 26, 2017 at 3:48 AM, Razvan Cojocaru >> wrote: >>> Pending livepatch code wants to check if the vm_event wait queues >>> are

Re: [Xen-devel] [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place

On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote: > Normally the __p4d() macro would be used and that would be ok whether > CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the > paravirt ops path I have to use native_make_p4d(). So __p4d is in !CONFIG_PARAVIRT path.

[Xen-devel] [ovmf test] 111067: all pass - PUSHED

flight 111067 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/111067/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 578dbd52b70061fd3442dc5b050479e4f13b9585 baseline version: ovmf

[Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

Xen Live Patching has been available as tech preview feature since Xen 4.7 and has now had a couple of releases to stabilize. Xen Live patching has been used by multiple vendors to fix several real-world security issues without any severe bugs encountered. Additionally, there are now tests in

Re: [Xen-devel] [PATCH] x86/boot: re-arrange how/when we do disk I/O

> -Original Message- > From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: 26 June 2017 14:04 > To: Jan Beulich > Cc: Andrew Cooper ; Paul Durrant > ; xen-devel ; > Lars Kurth

Re: [Xen-devel] [PATCH] common/vm_event: Initialize vm_event lists on domain creation

On 26/06/17 15:52, Tamas K Lengyel wrote: > On Mon, Jun 26, 2017 at 3:48 AM, Razvan Cojocaru > wrote: >> Pending livepatch code wants to check if the vm_event wait queues >> are active, and this is made harder by the fact that they were >> previously only initialized

Re: [Xen-devel] [PATCH] common/vm_event: Initialize vm_event lists on domain creation

On Mon, Jun 26, 2017 at 3:48 AM, Razvan Cojocaru wrote: > Pending livepatch code wants to check if the vm_event wait queues > are active, and this is made harder by the fact that they were > previously only initialized some time after the domain was created, > in

Re: [Xen-devel] [PATCH v3 7/9] vpci: add a priority field to the vPCI register initializer

On Tue, May 23, 2017 at 06:52:42AM -0600, Jan Beulich wrote: > >>> On 27.04.17 at 16:35, wrote: > > +#define REGISTER_VPCI_INIT(f, p)\ > > + static const struct vpci_register_init\ > > +

Re: [Xen-devel] [PATCH v2] rombios: prevent building with PIC/PIE

On 26/06/17 14:00, Andrew Cooper wrote: > On 26/06/17 13:55, Olaf Hering wrote: >> If the default compiler silently defaults to to -fPIC/-fPIE building >> rombios fails: >> >> ld -melf_i386 -s -r 32bitbios.o tcgbios/tcgbiosext.o util.o pmm.o -o >> 32bitbios_all.o >> There are undefined symbols

[Xen-devel] [qemu-upstream-4.6-testing test] 111045: regressions - FAIL

flight 111045 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/111045/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 10 debian-di-installfail REGR. vs. 106835

[Xen-devel] [PATCH] mini-os: link to libgcc.a to fix build with gcc7

gcc7 generates a call to __udivmoddi4 ... stubdom/mini-os-x86_32-grub/mini-os.o: In function `_strtoll_r': stubdom/newlib-x86_32/i686-xen-elf/newlib/libc/stdlib/../../../../../newlib-1.16.0/newlib/libc/stdlib/strtoll_r.c:110: undefined reference to `__udivmoddi4' make[2]: *** [Makefile:167:

Re: [Xen-devel] [PATCH] x86/mm: Fix infinite loop in get_spage_pages()

On Mon, Jun 26, 2017 at 12:59:02PM +0100, Andrew Cooper wrote: > c/s 2b8eb37 switched int i to being unsigned, but the undo logic on failure > relied in i being signed. As i being unsigned in still preforable, adjust the > undo logic to work with an unsigned i. > > Coverity-ID: 1413017 >

Re: [Xen-devel] [PATCH] x86/xen: allow userspace access during hypercalls

> -Original Message- > From: 'Marek Marczykowski-Górecki' > [mailto:marma...@invisiblethingslab.com] > Sent: 26 June 2017 14:22 > To: Paul Durrant > Cc: Juergen Groß ; Andrew Cooper > ; x...@kernel.org; linux- >

Re: [Xen-devel] [PATCH] x86/xen: allow userspace access during hypercalls

On Mon, Jun 26, 2017 at 01:09:58PM +, Paul Durrant wrote: > > -Original Message- > > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > > Marek Marczykowski-Górecki > > Sent: 26 June 2017 13:45 > > To: Juergen Groß > > Cc: Andrew Cooper

[Xen-devel] [xen-4.7-testing baseline-only test] 71598: tolerable trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71598 xen-4.7-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71598/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested-intel 16

Re: [Xen-devel] [PATCH v2 01/16] xen/mm: Don't use _{g, m}fn for defining INVALID_{G, M}FN

Hi, On 23/06/17 10:31, Jan Beulich wrote: On 23.06.17 at 11:24, wrote: At 03:18 -0600 on 23 Jun (1498187924), Jan Beulich wrote: How about: - keep INVALID_MFN as an inline function call for most uses; - #define INVALID_MFN_INITIALIZER { ~0UL } for when we need a real

Re: [Xen-devel] [PATCH] x86/xen: allow userspace access during hypercalls

> -Original Message- > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of > Marek Marczykowski-Górecki > Sent: 26 June 2017 13:45 > To: Juergen Groß > Cc: Andrew Cooper ; x...@kernel.org; linux- > ker...@vger.kernel.org;

Re: [Xen-devel] [RFC v2] Proposal: Fuzzing the Hypervisor

Nice write-up. Overall this is in line with what we discussed, so I don't really have more comments. On Sat, Jun 24, 2017 at 08:42:50AM +0200, Felix Schmoll wrote: [...] > == > 3.3 Fuzzer > == > The idea is to create some dictionary

Re: [Xen-devel] [PATCH] x86/boot: re-arrange how/when we do disk I/O

Hi, On 12/06/17 17:59, Julien Grall wrote: Hi Jan, On 12/06/17 16:27, Jan Beulich wrote: On 12.06.17 at 17:11, wrote: We place the trampoline no lower than at 256k, so we have ample space to read the MBRs of BIOS disks into an aligned buffer right below the trampoline

Re: [Xen-devel] [PATCH v2] rombios: prevent building with PIC/PIE

On 26/06/17 13:55, Olaf Hering wrote: > If the default compiler silently defaults to to -fPIC/-fPIE building > rombios fails: > > ld -melf_i386 -s -r 32bitbios.o tcgbios/tcgbiosext.o util.o pmm.o -o > 32bitbios_all.o > There are undefined symbols in the BIOS: > U _GLOBAL_OFFSET_TABLE_

[Xen-devel] [distros-debian-sid test] 71599: tolerable trouble: blocked/broken/fail/pass

flight 71599 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71599/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-i386-sid-netboot-pvgrub 10 guest-start fail blocked in 71584

[Xen-devel] [PATCH v2] rombios: prevent building with PIC/PIE

If the default compiler silently defaults to to -fPIC/-fPIE building rombios fails: ld -melf_i386 -s -r 32bitbios.o tcgbios/tcgbiosext.o util.o pmm.o -o 32bitbios_all.o There are undefined symbols in the BIOS: U _GLOBAL_OFFSET_TABLE_ make[10]: *** [Makefile:26: 32bitbios_all.o]

[Xen-devel] [PATCH v2] x86/xen: allow userspace access during hypercalls

Userspace application can do a hypercall through /dev/xen/privcmd, and some for some hypercalls argument is a pointers to user-provided structure. When SMAP is supported and enabled, hypervisor can't access. So, lets allow it. The same applies to HYPERVISOR_dm_op, where additionally privcmd

Re: [Xen-devel] [PATCH] x86/xen: allow userspace access during hypercalls

On Mon, Jun 26, 2017 at 02:05:48PM +0200, Juergen Groß wrote: > On 06/23/2017 02:47 PM, Marek Marczykowski-Górecki wrote: > > Userspace application can do a hypercall through /dev/xen/privcmd, and > > some for some hypercalls argument is a pointers to user-provided > > structure. When SMAP is

[Xen-devel] [xen-4.8-testing test] 111043: tolerable trouble: blocked/broken/fail/pass - PUSHED

flight 111043 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/111043/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1

Re: [Xen-devel] [PATCH] common/vm_event: Initialize vm_event lists on domain creation

On 06/26/2017 03:14 PM, Andrew Cooper wrote: > Razvan: I'd reword this to not mention livepatching. Simply having > list_empty() working is a good enough reason alone. Fair enough, I'll change the patch description as soon as we hear from Tamas, so that I might address as many comments as

Re: [Xen-devel] [PATCH] common/vm_event: Initialize vm_event lists on domain creation

On 26/06/17 12:39, Konrad Rzeszutek Wilk wrote: > On June 26, 2017 5:48:17 AM EDT, Razvan Cojocaru > wrote: >> Pending livepatch code wants to check if the vm_event wait queues >> are active, and this is made harder by the fact that they were > > Hmm, it wants to? Is

Re: [Xen-devel] [PATCH] x86/mm: Fix infinite loop in get_spage_pages()

On June 26, 2017 7:59:02 AM EDT, Andrew Cooper wrote: >c/s 2b8eb37 switched int i to being unsigned, but the undo logic on >failure >relied in i being signed. As i being unsigned in still preforable, >adjust the >undo logic to work with an unsigned i. > >Coverity-ID:

Re: [Xen-devel] [PATCH] x86/xen: allow userspace access during hypercalls

On 06/23/2017 02:47 PM, Marek Marczykowski-Górecki wrote: Userspace application can do a hypercall through /dev/xen/privcmd, and some for some hypercalls argument is a pointers to user-provided structure. When SMAP is supported and enabled, hypervisor can't access. So, lets allow it. What

Re: [Xen-devel] [PATCH] x86: xen: remove unnecessary variable in xen_foreach_remap_area()

On 06/24/2017 12:01 AM, Gustavo A. R. Silva wrote: Remove unnecessary variable mfn in function xen_foreach_remap_area() and, refactor the code. Variable mfn at line 518:mfn = xen_remap_buf.mfns[i]; is only being used to store a value to be passed as an argument to the xen_update_mem_tables()

[Xen-devel] [PATCH] x86/mm: Fix infinite loop in get_spage_pages()

c/s 2b8eb37 switched int i to being unsigned, but the undo logic on failure relied in i being signed. As i being unsigned in still preforable, adjust the undo logic to work with an unsigned i. Coverity-ID: 1413017 Signed-off-by: Andrew Cooper --- CC: Jan Beulich

Re: [Xen-devel] [PATCH] rombios: prevent building with PIC

>>> Olaf Hering 06/26/17 8:47 AM >>> >Am Mon, 26 Jun 2017 00:30:50 -0600 >schrieb "Jan Beulich" : > >> In the description you also talk about PIE, but you deal with PIC only here. >> Is that intentional? If so, please say why in the description. > >Thats what

Re: [Xen-devel] [PATCH v3 6/9] xen/vpci: trap access to the list of PCI capabilities

On Tue, May 23, 2017 at 06:49:50AM -0600, Jan Beulich wrote: > >>> On 27.04.17 at 16:35, wrote: > > Add traps to each capability PCI_CAP_LIST_NEXT field in order to mask them > > on > > request. > > > > All capabilities from the device are fetched and stored in an internal

[Xen-devel] [PATCH] x86/mm: revert to int type in get_spage_pages

2b8eb379930 changed the type of i to be unsigned, but the inner loop depends on it being a signed type. Coverity-ID: 1413017 Signed-off-by: Wei Liu --- Cc: Tim Deegan Cc: George Dunlap Cc: Jan Beulich Cc:

Re: [Xen-devel] [PATCH] common/vm_event: Initialize vm_event lists on domain creation

On 06/26/2017 02:39 PM, Konrad Rzeszutek Wilk wrote: > On June 26, 2017 5:48:17 AM EDT, Razvan Cojocaru > wrote: >> Pending livepatch code wants to check if the vm_event wait queues >> are active, and this is made harder by the fact that they were > > > Hmm, it wants

Re: [Xen-devel] [PATCH] common/vm_event: Initialize vm_event lists on domain creation

On June 26, 2017 5:48:17 AM EDT, Razvan Cojocaru wrote: >Pending livepatch code wants to check if the vm_event wait queues >are active, and this is made harder by the fact that they were Hmm, it wants to? Is there an missing patch that hasn't been posted for this?

Re: [Xen-devel] DomU can't start after recompiling DomU(PV) OS kernel

On 06/26/2017 08:37 AM, 謝 東曄 wrote: Xen Version:4.5.5 Guest OS(DomU OS):Ubuntu 14.04 Old kernel: 4.4.0 new recompile Kernel : 4.4.31 // Install DomU OS in image file first, i use dd if=/dev/zero of=test.img bs=1M count=20480 to create 20G empty image file. then use xl create vm.cfg command to

[Xen-devel] [PATCH v1 4/6] vvmx: add hvm_max_vmx_msr_policy

Currently, when nested virt is enabled, the set of L1 VMX features is fixed and calculated by nvmx_msr_read_intercept() as an intersection between the full set of Xen's supported L1 VMX features, the set of actual H/W features and, for MSR_IA32_VMX_EPT_VPID_CAP, the set of features that Xen uses.

[Xen-devel] [PATCH v1 2/6] vmx: add raw_vmx_msr_policy

Add calculate_raw_policy() which fills raw_vmx_msr_policy (the actual contents of H/W VMX MSRs) on the boot CPU. On secondary CPUs, this function checks that contents of VMX MSRs match the boot CPU's contents. Remove lesser version of same-contents-check from vmx_init_vmcs_config().

[Xen-devel] [PATCH v1 3/6] vmx: refactor vmx_init_vmcs_config()

1. Remove RDMSRs of VMX MSRs since all values are already available in raw_vmx_msr_policy. 2. Replace bit operations involving VMX bitmasks with accessing VMX features by name and using vmx_msr_available() where appropriate. Signed-off-by: Sergey Dyasli ---

[Xen-devel] [DEBUG PATCH 6/6] vmx: print H/W VMX MSRs values during startup

This is a debug patch I used when developing this series. It's not intended for merging, I post it because it might be useful to someone. Signed-off-by: Sergey Dyasli --- xen/arch/x86/hvm/vmx/vmcs.c | 405 1 file changed,

[Xen-devel] [PATCH v1 5/6] vvmx: add per domain vmx msr policy

Having a policy per domain allows to sensibly query what VMX features the domain has, which unblocks some other nested virt work items. For now, make policy for each domain equal to hvm_max_vmx_msr_policy. In the future it should be possible to independently configure the policy for each domain.

[Xen-devel] [PATCH v1 0/6] VMX MSRs policy for Nested Virt: part 1

The end goal of having VMX MSRs policy is to be able to manage L1 VMX features. This patch series is the first part of this work. There is no functional change to what L1 sees in VMX MSRs at this point. But each domain will have a policy object which allows to sensibly query what VMX features the

[Xen-devel] [PATCH v1 1/6] vmx: add struct vmx_msr_policy

This structure provides a convenient way of accessing contents of VMX MSRs: every bit value is accessible by its name. Bit names match existing Xen's definitions as close as possible. The structure also contains the bitmap of available MSRs since not all of them may be available on a particular

Re: [Xen-devel] [RFC v2] Proposal: Fuzzing the Hypervisor

On Sat, Jun 24, 2017 at 7:42 AM, Felix Schmoll wrote: > Hi, > > here a new version of my proposal for fuzzing the hypervisor. The original > can be found here: [1]. > > == > 1. Motivation and Description >

Re: [Xen-devel] [PATCH RFC] Live migration for VMs with QEMU backed local storage

On Fri, Jun 23, 2017 at 9:03 AM, Roger Pau Monné wrote: > On Fri, Jun 23, 2017 at 03:42:20AM -0400, Bruno Alvisio wrote: >> This patch is the first attempt on adding live migration of instances with >> local >> storage to Xen. This patch just handles very restricted case of

[Xen-devel] [PATCH] common/vm_event: Initialize vm_event lists on domain creation

Pending livepatch code wants to check if the vm_event wait queues are active, and this is made harder by the fact that they were previously only initialized some time after the domain was created, in vm_event_enable(). This patch initializes the lists immediately after xzalloc()ating the vm_event

[Xen-devel] [PATCH v6.1 1/3] x86/vioapic: make gsi_vioapic private

And introduce vioapic_get_{mask/vector} in order to replace it's usage. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- Cc: Jan Beulich Cc: Andrew Cooper --- Changes since v6: - Constify domain

Re: [Xen-devel] clean up and modularize arch dma_mapping interface V2

On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote: > I think we still need to do it. For example we have a bunch new "funky" > cases. I have no plan to do away with the selection - I just want a better interface than the current one.

[Xen-devel] [PATCH v6.1 2/3] x86/pt: enable binding of GSIs to a PVH Dom0

Achieve this by expanding pt_irq_create_bind in order to support mapping interrupts of type PT_IRQ_TYPE_PCI to a PVH Dom0. GSIs bound to Dom0 are always identity bound, which means the all the fields inside of the u.pci sub-struct are ignored, and only the machine_irq is actually used in order to

  1   2   >