[Xen-devel] [xen-unstable-smoke test] 106677: regressions - trouble: blocked/broken/fail/pass

flight 106677 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106677/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-buildfail REGR. vs. 106664 Tests which

Re: [Xen-devel] [PATCH v2] boot allocator: Use arch helper for virt_to_mfn on DIRECTMAP

On Tue, Mar 14, 2017 at 9:02 PM, Julien Grall wrote: > Hello Vijay, > > On 13/03/17 11:43, vijay.kil...@gmail.com wrote: >> >> From: Vijaya Kumar K >> >> On ARM, virt_to_mfn uses the hardware for address >> translation. So if the virtual address is

Re: [Xen-devel] [PATCH v3 4/7] xen/9pfs: connect to the backend

On 14/03/17 22:22, Stefano Stabellini wrote: > Hi Juergen, > > thank you for the review! > > On Tue, 14 Mar 2017, Juergen Gross wrote: >> On 14/03/17 00:50, Stefano Stabellini wrote: >>> Implement functions to handle the xenbus handshake. Upon connection, >>> allocate the rings according to the

Re: [Xen-devel] [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

,"Luis R . Rodriguez" ,Stanislaw Gruszka ,Peter Zijlstra ,Josh Poimboeuf ,Vitaly Kuznetsov ,Tim Chen ,Joerg Roedel

[Xen-devel] [xen-4.6-testing test] 106663: tolerable FAIL - PUSHED

flight 106663 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/106663/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 106556

[Xen-devel] [xen-unstable-smoke test] 106675: regressions - trouble: blocked/broken/fail/pass

flight 106675 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106675/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-buildfail REGR. vs. 106664 Tests which

Re: [Xen-devel] [PATCH v8 08/24] x86: refactor psr: set value: implement framework.

On 17-03-14 04:24:51, Jan Beulich wrote: > >>> On 14.03.17 at 10:21, wrote: > > On 17-03-14 00:29:09, Jan Beulich wrote: > >> >>> Yi Sun 03/14/17 3:42 AM >>> > >> >There are three scenarios. E.g. > >> >1. User calls domctl interface on Dom0 to

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

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

[Xen-devel] [PATCH] tools/xl/xl_parse.c: Remove blank line.

Address Liu wei's comments. Signed-off-by: Zhang Chen --- tools/xl/xl_parse.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 0787337..faa9c61 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -524,7

Re: [Xen-devel] [PATCH V4 7/8] COLO-Proxy: Use socket to get checkpoint event.

On 03/14/2017 07:24 PM, Wei Liu wrote: On Mon, Mar 06, 2017 at 10:59:25AM +0800, Zhang Chen wrote: We use kernel colo proxy's way to get the checkpoint event from qemu colo-compare. Qemu colo-compare need add a API to support this(I will add this in qemu). Qemu side patch:

Re: [Xen-devel] [PATCH V4 5/8] COLO-Proxy: Add secondary userspace colo-proxy start args

On 03/14/2017 07:39 PM, Wei Liu wrote: On Tue, Mar 14, 2017 at 11:24:12AM +, Wei Liu wrote: On Mon, Mar 06, 2017 at 10:59:23AM +0800, Zhang Chen wrote: Qemu need this args to start userspace colo-proxy. Signed-off-by: Zhang Chen Acked-by: Wei Liu

[Xen-devel] [xen-4.7-testing test] 106661: tolerable FAIL - PUSHED

flight 106661 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/106661/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 106540

[Xen-devel] [xen-unstable-smoke test] 106673: regressions - trouble: blocked/broken/fail/pass

flight 106673 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106673/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-buildfail REGR. vs. 106664 Tests which

Re: [Xen-devel] [PATCH v2 1/9] configure: change CONFIG_XEN_BACKEND to be a target property

On Tue, 14 Mar 2017 13:23:09 -0700 (PDT) Stefano Stabellini wrote: > On Tue, 14 Mar 2017, Stefano Stabellini wrote: > > On Tue, 14 Mar 2017, Paolo Bonzini wrote: > > > On 14/03/2017 00:55, Stefano Stabellini wrote: > > > > CONFIG_XEN_BACKEND is currently set when the

[Xen-devel] [linux-linus test] 106660: regressions - FAIL

flight 106660 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/106660/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254

Re: [Xen-devel] [PATCH 07/18] xen/arm: Introduce a command line parameter for SErrors/Aborts

On Mon, 13 Mar 2017, Wei Chen wrote: > In order to distinguish guest-generated SErrors from hypervisor-generated > SErrors. We have to place SError checking code in every EL1 -> EL2 paths. ^ remove . > That will be an overhead on entries caused by dsb/isb. > > But not all platforms want

Re: [Xen-devel] [PATCH 06/18] xen/arm: Introduce a virtual abort injection helper

On Mon, 13 Mar 2017, Wei Chen wrote: > When guest triggers async aborts, in most platform, such aborts > will be routed to hypervisor. But we don't want the hypervisor > to handle such aborts, so we have to route such aborts back to > the guest. > > This helper is using the HCR_EL2.VSE (HCR.VA

Re: [Xen-devel] [PATCH 04/18] xen/arm: Save HCR_EL2 when a guest took the SError

On Mon, 13 Mar 2017, Wei Chen wrote: > The HCR_EL2.VSE (HCR.VA for aarch32) bit can be used to generate a > virtual abort to guest. The HCR_EL2.VSE bit has a peculiar feature > of getting cleared when the guest has taken the abort (this is the > only bit that behaves as such in HCR_EL2 register).

Re: [Xen-devel] [PATCH 03/18] xen/arm: Avoid setting/clearing HCR_RW at every context switch

On Mon, 13 Mar 2017, Wei Chen wrote: > The HCR_EL2 flags for 64-bit and 32-bit domains are different. But > when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of > DomU in vcpu_initialise, we didn't know the domain's address size > information. We had to use compatible flags to

Re: [Xen-devel] [PATCH 02/18] xen/arm: Restore HCR_EL2 register

On Mon, 13 Mar 2017, Wei Chen wrote: > Different domains may have different HCR_EL2 flags. For example, the > 64-bit domain needs HCR_RW flag but the 32-bit does not need it. So > we give each domain a default HCR_EL2 value and save it in the VCPU's > context. > > HCR_EL2 register has only one

Re: [Xen-devel] [PATCH 01/18] xen/arm: Introduce a helper to get default HCR_EL2 flags

On Mon, 13 Mar 2017, Wei Chen wrote: > We want to add HCR_EL2 register to Xen context switch. And each copy > of HCR_EL2 in vcpu structure will be initialized with the same set > of trap flags as the HCR_EL2 register. We introduce a helper here to > represent these flags to be reused easily. > >

[Xen-devel] [xen-unstable-smoke test] 106672: regressions - trouble: blocked/broken/fail/pass

flight 106672 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106672/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-buildfail REGR. vs. 106664 Tests which

Re: [Xen-devel] [PATCH 3/3] xen/arm: p2m: Perform local TLB invalidation on vCPU migration

On Tue, 14 Mar 2017, Julien Grall wrote: > Hi Stefano, > > On 03/14/2017 10:39 PM, Stefano Stabellini wrote: > > On Wed, 8 Mar 2017, Julien Grall wrote: > > > On 08/03/2017 19:48, Stefano Stabellini wrote: > > > > On Wed, 8 Mar 2017, Julien Grall wrote: > > I see your point, it is a good idea to

Re: [Xen-devel] [PATCH 3/3] xen/arm: p2m: Perform local TLB invalidation on vCPU migration

Hi Stefano, On 03/14/2017 10:39 PM, Stefano Stabellini wrote: On Wed, 8 Mar 2017, Julien Grall wrote: On 08/03/2017 19:48, Stefano Stabellini wrote: On Wed, 8 Mar 2017, Julien Grall wrote: I see your point, it is a good idea to use the remaining space in struct domain. The only issue is that

Re: [Xen-devel] [PATCH 3/3] xen/arm: p2m: Perform local TLB invalidation on vCPU migration

On Wed, 8 Mar 2017, Julien Grall wrote: > On 08/03/2017 19:48, Stefano Stabellini wrote: > > On Wed, 8 Mar 2017, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 08/03/17 18:58, Stefano Stabellini wrote: > > > > On Wed, 8 Mar 2017, Julien Grall wrote: > > > > > The ARM architecture allows an

[Xen-devel] [PATCH 2/3] Introduce the Xen 9pfs transport header

Define the ring according to the protocol specification, using the new DEFINE_XEN_FLEX_RING_AND_INTF macro. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com --- xen/include/public/io/9pfs.h | 42 ++ 1 file changed, 42

[Xen-devel] [PATCH 1/3] [RESEND v4] ring.h: introduce macros to handle monodirectional rings with multiple req sizes

This patch introduces macros, structs and functions to handle rings in the format described by docs/misc/pvcalls.markdown and docs/misc/9pfs.markdown. The index page (struct __name##_data_intf) contains the indexes and the grant refs to setup two rings. Indexes page

[Xen-devel] [PATCH 3/3] Introduce the pvcalls header

Define the ring and request and response structs according to the specification. Use the new DEFINE_XEN_FLEX_RING macro. Signed-off-by: Stefano Stabellini CC: konrad.w...@oracle.com --- xen/include/public/io/pvcalls.h | 138 1 file

[Xen-devel] [xen-unstable-smoke test] 106670: regressions - trouble: blocked/broken/fail/pass

flight 106670 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106670/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-buildfail REGR. vs. 106664 Tests which

[Xen-devel] [xen-4.8-testing test] 106659: tolerable FAIL - PUSHED

flight 106659 xen-4.8-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/106659/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106535

Re: [Xen-devel] [PATCH v3 4/7] xen/9pfs: connect to the backend

Hi Juergen, thank you for the review! On Tue, 14 Mar 2017, Juergen Gross wrote: > On 14/03/17 00:50, Stefano Stabellini wrote: > > Implement functions to handle the xenbus handshake. Upon connection, > > allocate the rings according to the protocol specification. > > > > Initialize a

Re: [Xen-devel] [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

On Tue, Mar 14, 2017 at 2:04 PM, Pavel Machek wrote: > On Tue 2017-03-14 10:05:08, Thomas Garnier wrote: >> This patch makes the GDT remapped pages read-only to prevent corruption. >> This change is done only on 64-bit. >> >> The native_load_tr_desc function was adapted to correctly

Re: [Xen-devel] Future x86 emulator direction

On 12/14/2016 09:37 AM, Razvan Cojocaru wrote: > On 12/14/2016 09:14 AM, Jan Beulich wrote: > On 13.12.16 at 23:02, wrote: >>> On 13/12/2016 21:55, Razvan Cojocaru wrote: On a somewhat related note, it's important to also figure out how best to avoid

Re: [Xen-devel] [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

On Tue 2017-03-14 10:05:08, Thomas Garnier wrote: > This patch makes the GDT remapped pages read-only to prevent corruption. > This change is done only on 64-bit. > > The native_load_tr_desc function was adapted to correctly handle a > read-only GDT. The LTR instruction always writes to the GDT

Re: [Xen-devel] [PATCH v3 6/7] xen/9pfs: receive responses

On Tue, 14 Mar 2017, Juergen Gross wrote: > On 14/03/17 00:50, Stefano Stabellini wrote: > > Upon receiving a notification from the backend, schedule the > > p9_xen_response work_struct. p9_xen_response checks if any responses are > > available, if so, it reads them one by one, calling

Re: [Xen-devel] [PATCH v3 3/7] xen/9pfs: introduce Xen 9pfs transport driver

On Tue, 14 Mar 2017, Juergen Gross wrote: > On 14/03/17 00:50, Stefano Stabellini wrote: > > Introduce the Xen 9pfs transport driver: add struct xenbus_driver to > > register as a xenbus driver and add struct p9_trans_module to register > > as v9fs driver. > > > > All functions are empty stubs

Re: [Xen-devel] [PATCH v2 1/9] configure: change CONFIG_XEN_BACKEND to be a target property

On Tue, 14 Mar 2017, Stefano Stabellini wrote: > On Tue, 14 Mar 2017, Paolo Bonzini wrote: > > On 14/03/2017 00:55, Stefano Stabellini wrote: > > > CONFIG_XEN_BACKEND is currently set when the host supports Xen, > > > regardless of the chosen targets. As a consequence, Xen backends can be > > >

Re: [Xen-devel] [PATCH v2 5/9] xen/9pfs: connect to the frontend

On Tue, 14 Mar 2017, Juergen Gross wrote: > On 14/03/17 00:55, Stefano Stabellini wrote: > > Write the limits of the backend to xenstore. Connect to the frontend. > > Upon connection, allocate the rings according to the protocol > > specification. > > > > Initialize a QEMUBH to schedule work upon

[Xen-devel] [xen-unstable test] 106652: tolerable FAIL - PUSHED

flight 106652 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/106652/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail in 106642 pass in 106652

Re: [Xen-devel] [PATCH v2 4/9] xen/9pfs: introduce Xen 9pfs backend

On Tue, 14 Mar 2017, Juergen Gross wrote: > On 14/03/17 00:55, Stefano Stabellini wrote: > > Introduce the Xen 9pfs backend: add struct XenDevOps to register as a > > Xen backend and add struct V9fsTransport to register as v9fs transport. > > > > All functions are empty stubs for now. > > > >

Re: [Xen-devel] [PATCH v2 08/17] tools: provide pkg-config file for libxengnttab

On 14/03/17 13:31, Juergen Gross wrote: > In order to be able to use pkg-config for obtaining linker- and > compiler-flags provide a xengnttab.pc and a xengntshr.pc file. > > Signed-off-by: Juergen Gross > Acked-by: Wei Liu What is xengntshr.pc actually

[Xen-devel] [xen-unstable-smoke test] 106667: regressions - trouble: blocked/broken/fail/pass

flight 106667 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106667/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-buildfail REGR. vs. 106664 Tests which

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

Hello, On Mon, Mar 13, 2017 at 10:21:45AM +0100, Michal Hocko wrote: > On Fri 10-03-17 13:00:37, Reza Arbab wrote: > > On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote: > > >OK, so while I was playing with this setup some more I probably got why > > >this is done this way. All new

[Xen-devel] [linux-4.1 test] 106655: regressions - FAIL

flight 106655 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/106655/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 104301 Tests which are

Re: [Xen-devel] [PATCH v2 1/9] configure: change CONFIG_XEN_BACKEND to be a target property

On Tue, 14 Mar 2017, Paolo Bonzini wrote: > On 14/03/2017 00:55, Stefano Stabellini wrote: > > CONFIG_XEN_BACKEND is currently set when the host supports Xen, > > regardless of the chosen targets. As a consequence, Xen backends can be > > enabled even on targets that don't support Xen. > > > >

Re: [Xen-devel] [PATCH v4] xen: don't save/restore the physmap on VM save/restore

On Tue, 14 Mar 2017, Igor Druzhinin wrote: > Saving/restoring the physmap to/from xenstore was introduced to > QEMU majorly in order to cover up the VRAM region restore issue. > The sequence of restore operations implies that we should know > the effective guest VRAM address *before* we have the

Re: [Xen-devel] [PATCH v3] xen: don't save/restore the physmap on VM save/restore

On Tue, 14 Mar 2017, Igor Druzhinin wrote: > On 13/03/17 21:15, Stefano Stabellini wrote: > > On Mon, 13 Mar 2017, Igor Druzhinin wrote: > >> Saving/restoring the physmap to/from xenstore was introduced to > >> QEMU majorly in order to cover up the VRAM region restore issue. > >> The sequence of

[Xen-devel] [PATCH] tools: Include due to glibc 2.25

To fix the follwing error with glibc 2.25: tap-ctl-allocate.c:109:13: error: In the GNU C Library, "makedev" is defined by . For historical compatibility, it is currently defined by as well, but we plan to remove this soon. To use "makedev", include directly. If you did not intend to use a

[Xen-devel] [PATCH v3 14/21] x86/xen: split suspend.c for PV and PVHVM guests

Slit the code in suspend.c into suspend_pv.c and suspend_hvm.c. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross --- Changes since v2: #include added to suspend_pv.c [kbuild test robot] --- arch/x86/xen/Makefile | 3 ++-

[Xen-devel] [PATCH v3 19/21] xen: create xen_create/destroy_contiguous_region() stubs for PVHVM only builds

xen_create_contiguous_region()/xen_create_contiguous_region() are PV-only, they both contain xen_feature(XENFEAT_auto_translated_physmap) check and bail in the very beginning. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross ---

[Xen-devel] [PATCH v3 18/21] xen/balloon: decorate PV-only parts with #ifdef CONFIG_XEN_PV

Balloon driver uses several PV-only concepts (xen_start_info, xen_extra_mem,..) and it seems the simpliest solution to make HVM-only build happy is to decorate these parts with #ifdefs. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross ---

[Xen-devel] [PATCH v3 21/21] x86/xen: rename some PV-only functions in smp_pv.c

After code split between PV and HVM some functions in xen_smp_ops have xen_pv_ prefix and some only xen_ which makes them look like they're common for both PV and HVM while they're not. Rename all the rest to have xen_pv_ prefix. Signed-off-by: Vitaly Kuznetsov Reviewed-by:

[Xen-devel] [PATCH v3 15/21] x86/xen: put setup.c, pmu.c and apic.c under CONFIG_XEN_PV

xen_pmu_init/finish() functions are used in suspend.c and enlighten.c, add stubs for now. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross --- arch/x86/xen/Kconfig | 2 +- arch/x86/xen/Makefile | 6 +++--- arch/x86/xen/pmu.h| 5 + 3

[Xen-devel] [PATCH v3 16/21] x86/xen: define startup_xen for XEN PV only

startup_xen references PV-only code, decorate it with #ifdef CONFIG_XEN_PV to make PV-free builds possible. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross --- arch/x86/xen/xen-head.S | 4 1 file changed, 4 insertions(+) diff --git

[Xen-devel] [PATCH v3 10/21] x86/xen: split off smp_hvm.c

Move PVHVM related code to smp_hvm.c. Drop 'static' qualifier from xen_smp_send_reschedule(), xen_smp_send_call_function_ipi(), xen_smp_send_call_function_single_ipi(), these functions will be moved to common smp code when smp_pv.c is split. Signed-off-by: Vitaly Kuznetsov

[Xen-devel] [PATCH v3 20/21] x86/xen: enable PVHVM-only builds

Now everything is in place and we can move PV-only code under CONFIG_XEN_PV. CONFIG_XEN_PV_SMP is created to support the change. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross --- arch/x86/xen/Kconfig | 4 arch/x86/xen/Makefile | 9

[Xen-devel] [PATCH v3 00/21] x86/xen: untangle PV and PVHVM guest support code

Changes since v2: - Rebase to 4.11.0-rc1+ - XEN_HAVE_PVMMU moved to config XEN_PV [Juergen Gross] - .pin_vcpu kept for x86_hyper_xen_hvm to support PVH Dom0 in future [Juergen Gross] - 'extern' qualifiers dropped from newly introduced function prototypes in headers [Juergen Gross] - A couple

[Xen-devel] [PATCH v3 12/21] x86/xen: split off mmu_hvm.c

Move PVHVM related code to mmu_hvm.c. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross --- arch/x86/xen/Makefile | 2 +- arch/x86/xen/mmu.c | 74 -- arch/x86/xen/mmu_hvm.c | 79

[Xen-devel] [PATCH v3 06/21] x86/xen: split off enlighten_pv.c

Basically, enlighten.c is renamed to enlighten_pv.c and some code moved out to common enlighten.c. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross --- Changes since v2: xen_pin_vcpu() left in enlighten.c --- arch/x86/xen/Makefile |4

[Xen-devel] [PATCH v3 11/21] x86/xen: split off smp_pv.c

Basically, smp.c is renamed to smp_pv.c and some code moved out to common smp.c. struct xen_common_irq delcaration ended up in smp.h. Reviewed-by: Juergen Gross Signed-off-by: Vitaly Kuznetsov --- arch/x86/xen/Makefile | 2 +- arch/x86/xen/smp.c| 488

[Xen-devel] [PATCH v3 17/21] x86/xen: create stubs for HVM-only builds in page.h

__pfn_to_mfn() is only used from PV code (mmu_pv.c, p2m.c) and from page.h where all functions calling it check for xen_feature(XENFEAT_auto_translated_physmap) first so we can replace it with any stub to make build happy. set_foreign_p2m_mapping()/clear_foreign_p2m_mapping() are used from

[Xen-devel] [PATCH v3 03/21] x86/xen: add CONFIG_XEN_PV to Kconfig

All code to support Xen PV will get under this new option. For the beginning, check for it in the common code. Signed-off-by: Vitaly Kuznetsov --- Changes since v2: select XEN_HAVE_PVMMU moved to config XEN_PV [Juergen Gross] --- arch/x86/kernel/cpu/hypervisor.c | 4

[Xen-devel] [PATCH v3 02/21] x86/xen: globalize have_vcpu_info_placement

have_vcpu_info_placement applies to both PV and HVM and as we're going to split the code we need to make it global. Rename to xen_have_vcpu_info_placement. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross --- arch/x86/xen/enlighten.c | 12

[Xen-devel] [PATCH v3 09/21] x86/xen: split xen_cpu_die()

Split xen_cpu_die() into xen_pv_cpu_die() and xen_hvm_cpu_die() to support further splitting of smp.c. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross --- arch/x86/xen/smp.c | 26 -- 1 file changed, 20 insertions(+), 6

[Xen-devel] [PATCH v3 07/21] x86/xen: split xen_smp_intr_init()/xen_smp_intr_free()

xen_smp_intr_init() and xen_smp_intr_free() have PV-specific code and as a praparatory change to splitting smp.c we need to split these fucntions. Create xen_smp_intr_init_pv()/xen_smp_intr_free_pv(). Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross

Re: [Xen-devel] DomU UEFI configuration

On Tue, Mar 14, 2017 at 02:06:09PM +, Marcos E. Matsunaga wrote: > Hi Anthony, > > > I am trying to run a DomU guest using OVMF. I have built xen staging with > --with-ovmf option. I am able to install a new guest but I am unable to boot > it (see the attached image). > > The xl.cfg file I

[Xen-devel] [PATCH v3 08/21] x86/xen: split xen_smp_prepare_boot_cpu()

Split xen_smp_prepare_boot_cpu() into xen_pv_smp_prepare_boot_cpu() and xen_hvm_smp_prepare_boot_cpu() to support further splitting of smp.c. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross --- arch/x86/xen/smp.c | 49

[Xen-devel] [PATCH v3 05/21] x86/xen: split off enlighten_hvm.c

Move PVHVM related code to enlighten_hvm.c. Three functions: xen_cpuhp_setup(), xen_reboot(), xen_emergency_restart() are shared, drop static qualifier from them. These functions will go to common code once it is split from enlighten.c. Signed-off-by: Vitaly Kuznetsov

[Xen-devel] [PATCH v3 01/21] x86/xen: separate PV and HVM hypervisors

As a preparation to splitting the code we need to untangle it: x86_hyper_xen -> x86_hyper_xen_hvm and x86_hyper_xen_pv xen_platform() -> xen_platform_hvm() and xen_platform_pv() xen_cpu_up_prepare() -> xen_cpu_up_prepare_pv() and xen_cpu_up_prepare_hvm() xen_cpu_dead() -> xen_cpu_dead_pv() and

[Xen-devel] [PATCH v3 04/21] x86/xen: split off enlighten_pvh.c

Create enlighten_pvh.c by splitting off PVH related code from enlighten.c, put it under CONFIG_XEN_PVH. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Juergen Gross --- Changes since v2: #include added [kbuild test robot] --- arch/x86/xen/Makefile

[Xen-devel] [xen-unstable-smoke test] 106666: regressions - trouble: blocked/broken/fail/pass

flight 10 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/10/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-buildfail REGR. vs. 106664 Tests which

[Xen-devel] [PATCH v7 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

This patch aligns MODULES_END to the beginning of the Fixmap section. It optimizes the space available for both sections. The address is pre-computed based on the number of pages required by the Fixmap section. It will allow GDT remapping in the Fixmap section. The current MODULES_END static

[Xen-devel] [PATCH v7 2/3] x86: Remap GDT tables in the Fixmap section

Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target other per-cpu structures or deduce the base of the main memory section

[Xen-devel] [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit

This patch makes the GDT remapped pages read-only to prevent corruption. This change is done only on 64-bit. The native_load_tr_desc function was adapted to correctly handle a read-only GDT. The LTR instruction always writes to the GDT TSS entry. This generates a page fault if the GDT is

Re: [Xen-devel] help please...

On Mon, Mar 13, 2017 at 10:36:50AM +0800, 刘瑞丰 wrote: > [image: 内嵌图片 1] > Please don't send pictures to mailing list. Not everyone can see them (some people use text based email clients) and they consume a lot of bandwidth combined. > it reports: > > checking for PyArg_ParseTuple in

[Xen-devel] [PATCH v4] xen: don't save/restore the physmap on VM save/restore

Saving/restoring the physmap to/from xenstore was introduced to QEMU majorly in order to cover up the VRAM region restore issue. The sequence of restore operations implies that we should know the effective guest VRAM address *before* we have the VRAM region restored (which happens later).

Re: [Xen-devel] [PATCH v3 2/4] x86: remove PVHv1 code

On Tue, Mar 14, 2017 at 10:27:25AM +, Wei Liu wrote: > On Mon, Mar 13, 2017 at 04:50:12PM +, Wei Liu wrote: > > On Fri, Mar 03, 2017 at 12:25:06PM +, Roger Pau Monne wrote: > > > This removal applies to both the hypervisor and the toolstack side of > > > PVHv1. > > > > > > Note that

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface

On Tue 14-03-17 12:05:59, YASUAKI ISHIMATSU wrote: > > > On 03/13/2017 05:19 AM, Michal Hocko wrote: > >On Fri 10-03-17 12:39:27, Yasuaki Ishimatsu wrote: > >>On 03/10/2017 08:58 AM, Michal Hocko wrote: [...] > >>># echo online_movable > /sys/devices/system/memory/memory34/state > >>># grep .

Re: [Xen-devel] WTH is going on with memory hotplug sysf interface

On 03/13/2017 05:19 AM, Michal Hocko wrote: On Fri 10-03-17 12:39:27, Yasuaki Ishimatsu wrote: On 03/10/2017 08:58 AM, Michal Hocko wrote: [...] OK so I did with -m 2G,slots=4,maxmem=4G -numa node,mem=1G -numa node,mem=1G which generated [...] [0.00] ACPI: SRAT: Node 0 PXM 0 [mem

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

On Tue, Mar 14, 2017 at 09:13:08AM -0600, Jan Beulich wrote: > >>> On 14.03.17 at 16:06, wrote: > > On Mon, Mar 13, 2017 at 05:48:44AM -0600, Jan Beulich wrote: > >> >>> On 10.03.17 at 18:10, wrote: > >> > On 28/02/17 09:31, Jan Beulich wrote: > >>

[Xen-devel] 2017 Xen Project Developer and Design Summit: CfP open from now to April 14, Event is held July 11-13, 2017 in Budapest

Dear Community Members, I am excited to announce that registration and the call for proposals is open for Xen Project Developer and Design Summit 2017, which will be held in Budapest, Hungary from July 11-13, 2017. The Xen Project Developer and Design Summit combines the formats of Xen

Re: [Xen-devel] [PATCH] xen/arm: Register re-mapped Xen area as a temporary virtual region

Hello Wei, On 14/03/17 09:27, Wei Chen wrote: While we're doing apply_alternatives, we will generate new instructions I didn't spot this on the first review. apply_alternatives does not call __apply_alternatives_multi_stop, so please clarify the problem. Cheers, -- Julien Grall

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

flight 106664 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/106664/ 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 build-arm64 5

Re: [Xen-devel] [PATCH] xen/arm: Register re-mapped Xen area as a temporary virtual region

Hello Wei, Title: I would add alternative to make clear this is touching alternative. On 14/03/17 09:27, Wei Chen wrote: While we're doing apply_alternatives, we will generate new instructions if required. The new instructions need to update the Xen text section, but Xen text section is

Re: [Xen-devel] [PATCH v2] boot allocator: Use arch helper for virt_to_mfn on DIRECTMAP

Hello Vijay, On 13/03/17 11:43, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K On ARM, virt_to_mfn uses the hardware for address translation. So if the virtual address is not mapped translation fault is raised.On ARM, DIRECTMAP_VIRT region is direct mapped. This

Re: [Xen-devel] [PATCH] tools: correct build in directory below tools

On Tue, Mar 14, 2017 at 04:04:41PM +0100, Juergen Gross wrote: > Recent changes to create *.pc files introduced a bug when trying to > build a library from a directory below tools as PKG_CONFIG_DIR wouldn't > be set. Correct this by adding a default value to Rules.mk. > > Signed-off-by: Juergen

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

>>> On 14.03.17 at 16:06, wrote: > On Mon, Mar 13, 2017 at 05:48:44AM -0600, Jan Beulich wrote: >> >>> On 10.03.17 at 18:10, wrote: >> > On 28/02/17 09:31, Jan Beulich wrote: >> > On 27.02.17 at 16:10, wrote: >> >>>

Re: [Xen-devel] [PATCH] tools/libxl: correct distclean target

On Tue, Mar 14, 2017 at 04:04:42PM +0100, Juergen Gross wrote: > Commit 3e5f1a63b53920763 ("tools: adapt xenlight.pc and xlutil.pc to > new pkg-config scheme") introduced an error for "make distclean" as > *.pc.in are deleted which are now files in git. > > Signed-off-by: Juergen Gross

Re: [Xen-devel] [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

On Tue, 2017-03-14 at 12:29 +, Reshetova, Elena wrote: > > Elena Reshetova writes: > > > > > refcount_t type and corresponding API should be > > > used instead of atomic_t when the variable is used as > > > a reference counter. This allows to avoid accidental > > >

Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

On Mon, Mar 13, 2017 at 05:48:44AM -0600, Jan Beulich wrote: > >>> On 10.03.17 at 18:10, wrote: > > On 28/02/17 09:31, Jan Beulich wrote: > > On 27.02.17 at 16:10, wrote: > >>> On 22/02/17 10:10, Jan Beulich wrote: > >>> On 22.02.17

[Xen-devel] [PATCH] tools/libxl: correct distclean target

Commit 3e5f1a63b53920763 ("tools: adapt xenlight.pc and xlutil.pc to new pkg-config scheme") introduced an error for "make distclean" as *.pc.in are deleted which are now files in git. Signed-off-by: Juergen Gross --- tools/libxl/Makefile | 1 - 1 file changed, 1 deletion(-)

[Xen-devel] [PATCH] tools: correct build in directory below tools

Recent changes to create *.pc files introduced a bug when trying to build a library from a directory below tools as PKG_CONFIG_DIR wouldn't be set. Correct this by adding a default value to Rules.mk. Signed-off-by: Juergen Gross --- tools/Rules.mk | 2 ++ 1 file changed, 2

Re: [Xen-devel] [PATCH] EFI: retrieve and expose Apple device properties

On 14/03/17 14:42, Jan Beulich wrote: > Apple's EFI drivers supply device properties which are needed to > support Macs optimally. They contain vital information which cannot be > obtained any other way (e.g. Thunderbolt Device ROM). They're also used > to convey the current device state so that

[Xen-devel] [qemu-mainline test] 106648: regressions - trouble: blocked/broken/fail/pass

flight 106648 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/106648/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 106641 REGR. vs.

Re: [Xen-devel] [PATCH] tools/libxc: Exposed XEN_DOMCTL_getvcpuextstate

On Tue, Mar 14, 2017 at 03:30:18PM +0200, Razvan Cojocaru wrote: > It's useful for an introspection tool to be able to inspect > XSAVE states. Xen already has a DOMCTL that can be used for this > purpose, but it had no public libxc wrapper. This patch adds > xc_vcpu_get_extstate(). > >

[Xen-devel] [PATCH] EFI: retrieve and expose Apple device properties

Apple's EFI drivers supply device properties which are needed to support Macs optimally. They contain vital information which cannot be obtained any other way (e.g. Thunderbolt Device ROM). They're also used to convey the current device state so that OS drivers can pick up where EFI drivers left

Re: [Xen-devel] [PATCH] x86emul: correct {,v}{ld,st}mxcsr handling

On 14/03/17 14:12, Jan Beulich wrote: > Calls to get_fpu() were missing. Calls to put_fpu() are deliberately > not being added: Neither instruction can raise #XM, so the catch-all > _put_fpu() is just fine here. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] [PATCH RFC 0/4] Fix issues with zero-length records in migration v2

On Tue, Mar 14, 2017 at 01:50:44PM +, Andrew Cooper wrote: > On 14/03/17 13:20, Julien Grall wrote: > > Hi Andrew, > > > > On 21/07/16 18:17, Andrew Cooper wrote: > >> This series is RFC because it has only had compile testing thusfar. > >> > >> On AMD hardware supporting Debug Extentions,

Re: [Xen-devel] [PATCH v2 04/17] tools: install PKG_INSTALLDIR in tools/Makefile

On Tue, Mar 14, 2017 at 02:31:11PM +0100, Juergen Gross wrote: > Instead of installing $(PKG_INSTALLDIR) in multiple Makefiles below > tools, do so in tools/Makefile. > > Signed-off-by: Juergen Gross Acked-by: Wei Liu

[Xen-devel] [PATCH] x86emul: correct {,v}{ld,st}mxcsr handling

Calls to get_fpu() were missing. Calls to put_fpu() are deliberately not being added: Neither instruction can raise #XM, so the catch-all _put_fpu() is just fine here. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++

  1   2   3   >