[Xen-devel] [ovmf baseline-only test] 72184: all pass

This run is configured for baseline tests only. flight 72184 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/72184/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 9425b34925d0cf1b96aaf2c316d3299df9780252 baseline

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

flight 113954 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/113954/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 113940 Tests which did not

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

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

Re: [Xen-devel] [PATCH v4 24/27] x86_32: assembly, add ENDs to some functions and relabel with SYM_CODE_*

On Mon, Oct 2, 2017 at 11:12 AM, Jiri Slaby wrote: > All these are functions which are invoked from elsewhere, but they are > not typical C functions. So we annotate them (as global) using the new > SYM_CODE_START. All these were not balanced with any END, so mark their > ends by

[Xen-devel] xen-pci-passthrough PCI Express support? (Re: [Qemu-devel] [PATCH v2 4/5] pci: Add INTERFACE_CONVENTIONAL_PCI_DEVICE to Conventional PCI devices)

On Thu, Sep 28, 2017 at 10:12:34AM -0300, Eduardo Habkost wrote: > On Thu, Sep 28, 2017 at 02:33:57AM -0600, Jan Beulich wrote: > > >>> On 27.09.17 at 21:56, wrote: > > > --- a/hw/xen/xen_pt.c > > > +++ b/hw/xen/xen_pt.c > > > @@ -964,6 +964,10 @@ static const TypeInfo

Re: [Xen-devel] [PATCH v3] xen/balloon: don't online new memory initially

Juergen Gross: > When setting up the Xenstore watch for the memory target size the new > watch will fire at once. Don't try to reach the configured target size > by onlining new memory in this case, as the current memory size will > be smaller in almost all cases due to e.g. BIOS reserved pages. >

Re: [Xen-devel] [PATCH v5 3/4] x86/xen/time: setup vcpu 0 time info page

On 10/02/2017 07:44 PM, Boris Ostrovsky wrote: > >> + >> +static void xen_setup_vsyscall_time_info(void) >> +{ >> +struct vcpu_register_time_memory_area t; >> +struct pvclock_vsyscall_time_info *ti; >> +int ret; > > > In the previous version you'd return immediately if >

[Xen-devel] [xen-unstable-smoke test] 113952: tolerable all pass - PUSHED

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

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Sat, Sep 23, 2017 at 2:43 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> > 2) we first implement the additional entropy bits that Linus suggested. >> > >> > does this work for you? >> >> Sure, I can look at how feasible that is. If it is, can

[Xen-devel] [xen-unstable test] 113950: regressions - FAIL

flight 113950 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/113950/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-bootfail REGR. vs. 113940

Re: [Xen-devel] [PATCH] migration, xen: Fix block image lock issue on live migration

Adding in kwolf; it looks sane to me; Kevin? If I'm reading this right, this is just after the device state save. Dave * Anthony PERARD (anthony.per...@citrix.com) wrote: > When doing a live migration of a Xen guest with libxl, the images for > block devices are locked by the original QEMU

Re: [Xen-devel] [PATCH v2 0/5] Towards work-conserving RTDS

On Mon, Oct 2, 2017 at 1:04 PM, Dario Faggioli wrote: > On Mon, 2017-10-02 at 17:38 +0300, Andrii Anisov wrote: > > Hello Meng Xu and Dario, > > > Hi, > > > On 01.09.17 18:58, Meng Xu wrote: > > > This series of patches make RTDS scheduler work-conserving > > > without

Re: [Xen-devel] [PATCH v5 3/4] x86/xen/time: setup vcpu 0 time info page

> + > +static void xen_setup_vsyscall_time_info(void) > +{ > + struct vcpu_register_time_memory_area t; > + struct pvclock_vsyscall_time_info *ti; > + int ret; In the previous version you'd return immediately if PVCLOCK_TSC_STABLE_BIT was not set. Don't you still need to check this?

Re: [Xen-devel] [PATCH v5 2/4] x86/xen/time: set pvclock flags on xen_time_init()

On 10/02/2017 02:31 PM, Joao Martins wrote: > Specifically check for PVCLOCK_TSC_STABLE_BIT and if this bit is set, > then set it too on pvclock flags. This allows Xen clocksource to use it > and thus speeding up xen_clocksource_read() callers (i.e. sched_clock()) > > Signed-off-by: Joao Martins

[Xen-devel] [PATCH v5 1/4] x86/pvclock: add setter for pvclock_pvti_cpu0_va

Right now there is only a pvclock_pvti_cpu0_va() which is defined on kvmclock since: commit dac16fba6fc5 ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap") The only user of this interface so far is kvm. This commit adds a setter function for the pvti page and moves

[Xen-devel] [PATCH v5 4/4] MAINTAINERS: xen, kvm: track pvclock-abi.h changes

This file defines an ABI shared between guest and hypervisor(s) (KVM, Xen) and as such there should be an correspondent entry in MAINTAINERS file. Notice that there's already a text notice at the top of the header file, hence this commit simply enforces it more explicitly and have both peers

[Xen-devel] [PATCH v5 3/4] x86/xen/time: setup vcpu 0 time info page

In order to support pvclock vdso on xen we need to setup the time info page for vcpu 0 and register the page with Xen using the VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall will also forcefully update the pvti which will set some of the necessary flags for vdso. Afterwards we

[Xen-devel] [PATCH v5 2/4] x86/xen/time: set pvclock flags on xen_time_init()

Specifically check for PVCLOCK_TSC_STABLE_BIT and if this bit is set, then set it too on pvclock flags. This allows Xen clocksource to use it and thus speeding up xen_clocksource_read() callers (i.e. sched_clock()) Signed-off-by: Joao Martins --- New in v5 ---

[Xen-devel] [PATCH v5 0/4] x86/xen: pvclock vdso support

Hey, This is take 5 for vdso for Xen. PVCLOCK_TSC_STABLE_BIT can be set starting Xen 4.8 which is required for vdso time related calls. In order to have it on, you need to have the hypervisor clocksource be TSC e.g. with the following boot params "clocksource=tsc tsc=stable:socket". Series is

Re: [Xen-devel] [PATCH v4 24/27] x86_32: assembly, add ENDs to some functions and relabel with SYM_CODE_*

On 10/02/2017 05:12 AM, Jiri Slaby wrote: > All these are functions which are invoked from elsewhere, but they are > not typical C functions. So we annotate them (as global) using the new > SYM_CODE_START. All these were not balanced with any END, so mark their > ends by SYM_CODE_END,

Re: [Xen-devel] [PATCH v4 23/27] x86_64: assembly, change all ENTRY+ENDPROC to SYM_FUNC_*

On 10/02/2017 05:12 AM, Jiri Slaby wrote: > These are all functions which are invoked from elsewhere, so we annotate > them as global using the new SYM_FUNC_START. And their ENDPROC's by > SYM_FUNC_END. > > And make sure ENTRY/ENDPROC is not defined on X86_64, given these were > the last users. >

Re: [Xen-devel] [PATCH v3 9/9] xen/arm: mm: Use memory flags for modify_xen_mappings rather than custom one

On Mon, Oct 02, 2017 at 06:31:50PM +0100, Julien Grall wrote: > This will help to consolidate the page-table code and avoid different > path depending on the action to perform. > > Signed-off-by: Julien Grall > Reviewed-by: Andre Przywara >

Re: [Xen-devel] [PATCH v4 22/27] x86_64: assembly, change all ENTRY+END to SYM_CODE_*

On 10/02/2017 05:12 AM, Jiri Slaby wrote: > Here, we change all code which is not marked as functions. In other > words, this code has been using END, not ENDPROC. So switch all of this > to appropriate new markings SYM_CODE_START and SYM_CODE_END. > > Signed-off-by: Jiri Slaby >

[Xen-devel] [xen-unstable-smoke test] 113951: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH 2/3 v4] xenfb: Use Input Handlers directly

On Tue, Sep 26, 2017 at 02:43:38PM +, Owen Smith wrote: > Avoid the unneccessary calls through the input-legacy.c file by > using the qemu_input_handler_*() calls directly. This did require > reworking the event and sync handlers to use the reverse mapping > from qcode to linux using

[Xen-devel] [PATCH v3 9/9] xen/arm: mm: Use memory flags for modify_xen_mappings rather than custom one

This will help to consolidate the page-table code and avoid different path depending on the action to perform. Signed-off-by: Julien Grall Reviewed-by: Andre Przywara Reviewed-by: Stefano Stabellini --- Cc: Konrad

[Xen-devel] [PATCH v3 3/9] xen/arm: mm: Rename and clarify AP[1] in the stage-1 page table

The description of AP[1] in Xen is based on testing rather than the ARM ARM. Per the ARM ARM, on EL2 stage-1 page table, AP[1] is RES1 as the translation regime applies to only one exception level (see D4.4.4 and G4.6.1 in ARM DDI 0487B.a). Update the comment and also rename the field to match

[Xen-devel] [PATCH v3 5/9] xen/arm: mm: Rename 'ai' into 'flags' in create_xen_entries

The parameter 'ai' is used either for attribute index or for permissions. Follow-up patch will rework that parameters to carry more information. So rename the parameter to 'flags'. Signed-off-by: Julien Grall Reviewed-by: Andre Przywara Reviewed-by:

[Xen-devel] [PATCH v3 0/9] xen/arm: Memory subsystem clean-up

Hi all, This patch series contains clean-up for the ARM memory subsystem in preparation of reworking the page tables handling. For all changes, see in each patch. Cheers, Julien Grall (9): xen/arm: page: Use ARMv8 naming to improve readability xen/arm: page: Clean-up the definition of

[Xen-devel] [PATCH v3 8/9] xen/arm: mm: Handle permission flags when adding a new mapping

Currently, all the new mappings will be read-write non-executable. Allow the caller to use other permissions. Signed-off-by: Julien Grall --- Changes in v2: - Switch the runtime check to a BUG_ON() --- xen/arch/arm/mm.c | 3 +++ 1 file changed, 3 insertions(+)

[Xen-devel] [PATCH v3 4/9] xen/arm: Switch to SYS_STATE_boot just after end_boot_allocator()

We should consider the early boot period to end when we stop using the boot allocator. This is inline with x86 and will be helpful to know whether we should allocate memory from the boot allocator or xenheap. Signed-off-by: Julien Grall Reviewed-by: Andre Przywara

[Xen-devel] [PATCH v3 7/9] xen/arm: mm: Embed permission in the flags

Currently, it is not possible to specify the permission of a new mapping. It would be necessary to use the function modify_xen_mappings with a different set of flags. Introduce a couple of new flags for the permissions (Non-eXecutable, Read-Only) and also provides definition that combine the

[Xen-devel] [PATCH v3 2/9] xen/arm: page: Clean-up the definition of MAIRVAL

Currently MAIRVAL is defined in term of MAIR0VAL and MAIR1VAL which are both hardcoded value. This makes quite difficult to understand the value written in both registers. Rework the definition by using value of each attribute shifted by their associated index. Signed-off-by: Julien Grall

[Xen-devel] [PATCH v3 1/9] xen/arm: page: Use ARMv8 naming to improve readability

This is based on the Linux ARMv8 naming scheme (see arch/arm64/mm/proc.S). Each type will contain "NORMAL" or "DEVICE" to make clear whether each attribute targets device or normal memory. Signed-off-by: Julien Grall --- Changes in v3: - The ai '000' is named

[Xen-devel] [PATCH v3 6/9] xen/arm: page: Describe the layout of flags used to update page tables

Currently, the flags used to update page tables (i.e PAGE_HYPERVISOR_*) only contains the memory attribute index. Follow-up patches will add more information in it. So document the current layout. At the same time introduce PAGE_AI_MASK to get the memory attribute index easily. Signed-off-by:

Re: [Xen-devel] [PATCH v3 00/15] xen/x86: Clean-up the PoD code

Hi George, On 10/02/2017 05:30 PM, George Dunlap wrote: On 10/02/2017 01:59 PM, Julien Grall wrote: Hi all, I have been attempting to use the PoD code on Arm (it will be sent in a separate series) and spent sometimes to clean-up and switch to typesafe gfn the current code. The PoD code has

Re: [Xen-devel] [PATCH v2 0/5] Towards work-conserving RTDS

On Mon, 2017-10-02 at 17:38 +0300, Andrii Anisov wrote: > Hello Meng Xu and Dario, > Hi, > On 01.09.17 18:58, Meng Xu wrote: > > This series of patches make RTDS scheduler work-conserving > > without breaking real-time guarantees. > > VCPUs with extratime flag set can get extra time > > from the

Re: [Xen-devel] [PATCH 3/3 v4] xenfb: Add [feature|request]-raw-pointer

On Tue, Sep 26, 2017 at 02:43:39PM +, Owen Smith wrote: > Writes "feature-raw-pointer" during init to indicate the backend > can pass raw unscaled values for absolute axes to the frontend. > Frontends set "request-raw-pointer" to indicate the backend should > not attempt to scale absolute

Re: [Xen-devel] [PATCH v4 21/27] x86_64: assembly, add ENDs to some functions and relabel with SYM_CODE_*

On 10/02/2017 05:12 AM, Jiri Slaby wrote: > All these are functions which are invoked from elsewhere, but they are > not typical C functions. So we annotate them (as global) using the new > SYM_CODE_START. All these were not balanced with any END, so mark their > ends by SYM_CODE_END,

Re: [Xen-devel] [PATCH v4 13/27] x86: xen-pvh, annotate data appropriatelly

On 10/02/2017 05:12 AM, Jiri Slaby wrote: > Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros: > 8 OBJECT LOCAL DEFAULT6 gdt > 000832 OBJECT LOCAL DEFAULT6 gdt_start > 0028 0 OBJECT LOCAL DEFAULT6 gdt_end > 0028 256 OBJECT LOCAL DEFAULT6

[Xen-devel] high CPU stolen time after live migrate

Hi, with Xen 4.8.2, migrated domains have wrong stats for stolen time. For example : root! laussor:/proc# cat stat cpu 87957976 32463 6483874 361169794 3075806 0 937004 183086986113 0 0 cpu0 2828867 2434 226580 43754152 786651 0 42766 1778722573131 0 0 cpu1 2611496 3545 232529 42364047 594846

[Xen-devel] [PATCH] migration, xen: Fix block image lock issue on live migration

When doing a live migration of a Xen guest with libxl, the images for block devices are locked by the original QEMU process, and this prevent the QEMU at the destination to take the lock and the migration fail. From QEMU point of view, once the RAM of a domain is migrated, there is two QMP

Re: [Xen-devel] [PATCH v3 00/15] xen/x86: Clean-up the PoD code

On 10/02/2017 01:59 PM, Julien Grall wrote: > Hi all, > > I have been attempting to use the PoD code on Arm (it will be sent in a > separate series) and spent sometimes to clean-up and switch to typesafe gfn > the current code. > > The PoD code has been tested on Arm (the version is slightly

Re: [Xen-devel] [PATCH v3 15/15] xen/x86: p2m-pod: Rework prototype of p2m_pod_demand_populate

On 10/02/2017 01:59 PM, Julien Grall wrote: > - Switch the return type to bool > - Remove the parameter p2m_query_t q as it is not used > > Signed-off-by: Julien Grall > Acked-by: Andrew Cooper > Reviewed-by: Wei Liu

Re: [Xen-devel] [PATCH v3 14/15] xen/x86: p2m-pod: Use typesafe gfn for the fields reclaim_single and max_guest

On 10/02/2017 01:59 PM, Julien Grall wrote: > Signed-off-by: Julien Grall > Acked-by: Andrew Cooper > Reviewed-by: Wei Liu Reviewed-by: George Dunlap

Re: [Xen-devel] [PATCH v3 13/15] xen/x86: p2m-pod: Use typesafe gfn in p2m_pod_demand_populate

On 10/02/2017 01:59 PM, Julien Grall wrote: > Signed-off-by: Julien Grall > Acked-by: Andrew Cooper > Reviewed-by: Wei Liu Reviewed-by: George Dunlap

Re: [Xen-devel] [PATCH v3 12/15] xen/x86: p2m-pod: Use typesafe gfn in p2m_pod_zero_check

On 10/02/2017 01:59 PM, Julien Grall wrote: > At the same time make the array gfns const has it is not modified within > the function. > > Signed-off-by: Julien Grall > Acked-by: Andrew Cooper > Reviewed-by: Wei Liu

[Xen-devel] [PATCH for-next 2/3] xen/x86: Introduce static inline wrappers for l{idt, gdt, ldt, tr}()

This avoids indirection and parameter constraint issues. Doing so relaxes the load_LDT() constraints from %ax to any general purpose register. The triple-fault reboot method stays as is, to avoid the int3 possibly getting moved relative to the lidt. Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH for-next 0/3] xen/x86: Misc improvements

Andrew Cooper (3): x86/smp: Rework cpu_smpboot_alloc() to cope with more than just -ENOMEM xen/x86: Introduce static inline wrappers for l{idt,gdt,ldt,tr}() x86/ldt: Alter how invalidate_shadow_ldt() deals with TLB flushes xen/arch/x86/cpu/common.c | 8 xen/arch/x86/domain.c

[Xen-devel] [PATCH for-next 1/3] x86/smp: Rework cpu_smpboot_alloc() to cope with more than just -ENOMEM

No functional change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: George Dunlap --- xen/arch/x86/smpboot.c | 31 ++- 1 file changed, 18

[Xen-devel] [PATCH for-next 3/3] x86/ldt: Alter how invalidate_shadow_ldt() deals with TLB flushes

Modify invalidate_shadow_ldt() to return a boolean indicating whether mappings have been dropped, rather than taking a flush parameter. Tweak the internal logic to be able to ASSERT() that v->arch.pv_vcpu.shadow_ldt_mapcnt matches the number of PTEs removed. This allows MMUEXTOP_SET_LDT to avoid

Re: [Xen-devel] [PATCH v3 11/15] xen/x86: p2m-pod: Clean-up p2m_pod_zero_check

On 10/02/2017 01:59 PM, Julien Grall wrote: > Signed-off-by: Julien Grall > Acked-by: Andrew Cooper Reviewed-by: George Dunlap ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH v3 10/15] xen/x86: p2m-pod: Use typesafe GFN in pod_eager_record

On 10/02/2017 01:59 PM, Julien Grall wrote: > Signed-off-by: Julien Grall > Acked-by: Andrew Cooper > Reviewed-by: Wei Liu Reviewed-by: George Dunlap

Re: [Xen-devel] [PATCH v3 09/15] xen/x86: p2m: Use typesafe GFN in p2m_set_entry

On 10/02/2017 01:59 PM, Julien Grall wrote: > Signed-off-by: Julien Grall > Acked-by: Andrew Cooper > Acked-by: Tamas K Lengyel > Reviewed-by: Wei Liu Reviewed-by: George Dunlap

Re: [Xen-devel] [PATCH v3 08/15] xen/x86: p2m: Use typesafe gfn for the P2M callbacks get_entry and set_entry

On Mon, Oct 2, 2017 at 6:59 AM, Julien Grall wrote: > Signed-off-by: Julien Grall > Acked-by: Andrew Cooper > Reviewed-by: Kevin Tian > Acked-by: Razvan Cojocaru >

Re: [Xen-devel] [PATCH v3 08/15] xen/x86: p2m: Use typesafe gfn for the P2M callbacks get_entry and set_entry

On 10/02/2017 01:59 PM, Julien Grall wrote: > Signed-off-by: Julien Grall > Acked-by: Andrew Cooper > Reviewed-by: Kevin Tian > Acked-by: Razvan Cojocaru > Reviewed-by: Wei Liu

Re: [Xen-devel] [PATCH v13 1/3] x86emul: New return code for unimplemented instruction

On 10/02/2017 03:42 PM, Petre Ovidiu PIRCALABU wrote: > On Lu, 2017-10-02 at 15:09 +0100, George Dunlap wrote: >> On 10/02/2017 02:43 PM, George Dunlap wrote: >>> >>> On 09/25/2017 01:03 PM, Petre Pircalabu wrote: Enforce the distinction between an instruction not implemented by the

[Xen-devel] [xen-unstable-smoke test] 113949: tolerable all pass - PUSHED

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

[Xen-devel] [linux-next test] 113947: regressions - FAIL

flight 113947 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/113947/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 6 kernel-build fail REGR. vs. 113902 Tests which did not

Re: [Xen-devel] [PATCH v13 1/3] x86emul: New return code for unimplemented instruction

On Lu, 2017-10-02 at 15:09 +0100, George Dunlap wrote: > On 10/02/2017 02:43 PM, George Dunlap wrote: > > > > On 09/25/2017 01:03 PM, Petre Pircalabu wrote: > > > > > > Enforce the distinction between an instruction not implemented by > > > the > > > emulator and the failure to emulate that

[Xen-devel] Release-ack before the code freeze

Hi all, To simplify things, I will forgo the requirement of release-ack until the code freeze and leave the call to the committers. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/5] Towards work-conserving RTDS

Hello Meng Xu and Dario, On 01.09.17 18:58, Meng Xu wrote: This series of patches make RTDS scheduler work-conserving without breaking real-time guarantees. VCPUs with extratime flag set can get extra time from the unreserved system resource. System administrators can decide which VCPUs have

Re: [Xen-devel] [PATCH v3 0/2] guard virt_spin_lock() with a static key

On Wed, Sep 06, 2017 at 07:36:23PM +0200, Juergen Gross wrote: > With virt_spin_lock() being guarded by a static key the bare metal case > can be optimized by patching the call away completely. In case a kernel > running as a guest it can decide whether to use paravitualized > spinlocks, the

Re: [Xen-devel] [RFC] removing proc-xen.mount due to systemd change

On 10/02/2017 03:55 PM, Franck Bui wrote: > > I think it would be better to continue the discussion here [1], as a > solution might require some changes on systemd side. > Actually I continued the discussion here: https://github.com/systemd/systemd/pull/6662 Feel free to join ! Thanks.

Re: [Xen-devel] [PATCH v2 01/47] Replace all occurances of __FUNCTION__ with __func__

On Fri, Sep 29, 2017 at 05:14:58PM -0700, Alistair Francis wrote: > Replace all occurs of __FUNCTION__ except for the check in checkpatch > with the non GCC specific __func__. > > One line in hcd-musb.c was manually tweaked to pass checkpatch. > > Signed-off-by: Alistair Francis

Re: [Xen-devel] [PATCH v13 1/3] x86emul: New return code for unimplemented instruction

On 10/02/2017 02:43 PM, George Dunlap wrote: > On 09/25/2017 01:03 PM, Petre Pircalabu wrote: >> Enforce the distinction between an instruction not implemented by the >> emulator and the failure to emulate that instruction by defining a new >> return code, X86EMUL_UNIMPLEMENTED. >> >> This value

Re: [Xen-devel] [RFC] removing proc-xen.mount due to systemd change

On 10/02/2017 12:35 PM, Wei Liu wrote: > On Mon, Oct 02, 2017 at 12:26:24PM +0200, Vasilis Liaskovitis wrote: >> - any other options? > > Can we just make the unit not fail? I.e. when it detects xenfs is > already mounted, it does nothing but reports success. > Unfortunately that's currently

Re: [Xen-devel] [PATCH v13 1/3] x86emul: New return code for unimplemented instruction

On 09/25/2017 01:03 PM, Petre Pircalabu wrote: > Enforce the distinction between an instruction not implemented by the > emulator and the failure to emulate that instruction by defining a new > return code, X86EMUL_UNIMPLEMENTED. > > This value should only be returned by the core emulator only if

Re: [Xen-devel] [PATCH v13 2/3] x86emul: Add return code information to error messages

On 09/25/2017 01:03 PM, Petre Pircalabu wrote: > - print the return code of the last failed emulator operation > in hvm_dump_emulation_state. > - print the return code in sh_page_fault (SHADOW_PRINTK) to make the > distiction between X86EMUL_UNHANDLEABLE and X86EMUL_UNIMPLEMENTED. > >

Re: [Xen-devel] [PATCH v13 1/3] x86emul: New return code for unimplemented instruction

On 09/25/2017 01:03 PM, Petre Pircalabu wrote: > Enforce the distinction between an instruction not implemented by the > emulator and the failure to emulate that instruction by defining a new > return code, X86EMUL_UNIMPLEMENTED. > > This value should only be returned by the core emulator only if

Re: [Xen-devel] [PATCH v2 23/24] xen/arm: mm: Handle permission flags when adding a new mapping

Hi Stefano, On 20/09/17 00:17, Stefano Stabellini wrote: On Tue, 12 Sep 2017, Julien Grall wrote: Currently, all the new mappings will be read-write non-executable. Allow the caller to use other permissions. Signed-off-by: Julien Grall --- Changes in v2:

Re: [Xen-devel] [PATCH] libxl: fix generating array of enums in getypes.py

On Mon, Oct 2, 2017 at 3:02 PM, Wei Liu wrote: > On Fri, Sep 29, 2017 at 04:49:23PM +0300, Oleksandr Grytsov wrote: >> From: Oleksandr Grytsov >> >> Enum always uses "x" value as input argument. In >> case of enum array "t" argument should be

[Xen-devel] [PATCH v3 00/15] xen/x86: Clean-up the PoD code

Hi all, I have been attempting to use the PoD code on Arm (it will be sent in a separate series) and spent sometimes to clean-up and switch to typesafe gfn the current code. The PoD code has been tested on Arm (the version is slightly different, mostly renaming) and the x86 part has only been

[Xen-devel] [PATCH v3 09/15] xen/x86: p2m: Use typesafe GFN in p2m_set_entry

Signed-off-by: Julien Grall Acked-by: Andrew Cooper Acked-by: Tamas K Lengyel Reviewed-by: Wei Liu --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew

[Xen-devel] [PATCH v3 11/15] xen/x86: p2m-pod: Clean-up p2m_pod_zero_check

Signed-off-by: Julien Grall Acked-by: Andrew Cooper --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Changes in v3: - Replace (foo == 0) by !foo

[Xen-devel] [PATCH v3 06/15] xen/x86: p2m-pod: Clean-up use of typesafe MFN

Some unboxing/boxing can be avoided by using mfn_add(...) instead. Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: George Dunlap Reviewed-by: Wei Liu --- Cc: George Dunlap

[Xen-devel] [PATCH v3 04/15] xen/x86: p2m-pod: Fix coding style

Also take the opportunity to: - move from 1 << * to 1UL << *. - use unsigned when possible - move from unsigned int -> unsigned long for some induction variables Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by:

[Xen-devel] [PATCH v3 02/15] xen/x86: p2m-pod: Remove trailing whitespaces

Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: George Dunlap Reviewed-by: Wei Liu --- Cc: George Dunlap Cc: Jan Beulich Cc:

[Xen-devel] [PATCH v3 14/15] xen/x86: p2m-pod: Use typesafe gfn for the fields reclaim_single and max_guest

Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: Wei Liu --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Changes in

[Xen-devel] [PATCH v3 15/15] xen/x86: p2m-pod: Rework prototype of p2m_pod_demand_populate

- Switch the return type to bool - Remove the parameter p2m_query_t q as it is not used Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: Wei Liu --- Cc: George Dunlap

[Xen-devel] [PATCH v3 01/15] xen/x86: p2m-pod: Clean-up includes

A lot of the headers are not necessary. At the same time, order them in the alphabetical order. Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: Wei Liu Acked-by: George Dunlap ---

[Xen-devel] [PATCH v3 10/15] xen/x86: p2m-pod: Use typesafe GFN in pod_eager_record

Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: Wei Liu --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Changes in

[Xen-devel] [PATCH v3 08/15] xen/x86: p2m: Use typesafe gfn for the P2M callbacks get_entry and set_entry

Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: Kevin Tian Acked-by: Razvan Cojocaru Reviewed-by: Wei Liu --- Cc: Jan Beulich Cc:

[Xen-devel] [PATCH v3 12/15] xen/x86: p2m-pod: Use typesafe gfn in p2m_pod_zero_check

At the same time make the array gfns const has it is not modified within the function. Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: Wei Liu --- Cc: George Dunlap Cc: Jan

[Xen-devel] [PATCH v3 13/15] xen/x86: p2m-pod: Use typesafe gfn in p2m_pod_demand_populate

Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: Wei Liu --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper Changes in

[Xen-devel] [PATCH v3 05/15] xen/x86: p2m-pod: Avoid redundant assignments in p2m_pod_demand_populate

gfn_aligned is assigned 3 times with the exact same formula. All the variables used are not modified, so consolidate in a single assignment at the beginning of the function. Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: George

[Xen-devel] [PATCH v3 07/15] xen/x86: p2m-pod: Use typesafe gfn in p2m_pod_decrease_reservation

Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: Wei Liu Acked-by: George Dunlap --- Cc: George Dunlap Cc: Jan Beulich Cc: Andrew

[Xen-devel] [PATCH v3 03/15] xen/x86: p2m-pod: Fix coding style for comments

Signed-off-by: Julien Grall Acked-by: Andrew Cooper Reviewed-by: George Dunlap Reviewed-by: Wei Liu --- Cc: George Dunlap Cc: Jan Beulich Cc:

Re: [Xen-devel] [PATCH v4 19/27] x86: assembly, make some functions local

On 2 October 2017 at 10:12, Jiri Slaby wrote: > There is a couple of assembly functions, which are invoked only locally > in the file they are defined. In C, we mark them "static". In assembly, > annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their > ENDPROC to

[Xen-devel] [xen-unstable-smoke test] 113948: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH v2 11/16] xen/x86: p2m-pod: Clean-up p2m_pod_zero_check

Hi Jan, On 22/09/17 10:26, Jan Beulich wrote: On 21.09.17 at 14:40, wrote: --- a/xen/arch/x86/mm/p2m-pod.c +++ b/xen/arch/x86/mm/p2m-pod.c @@ -861,17 +861,19 @@ p2m_pod_zero_check(struct p2m_domain *p2m, unsigned long *gfns, int count) for ( i = 0; i < count; i++

Re: [Xen-devel] [PATCH v4 23/27] x86_64: assembly, change all ENTRY+ENDPROC to SYM_FUNC_*

On Monday, October 2, 2017 11:12:42 AM CEST Jiri Slaby wrote: > These are all functions which are invoked from elsewhere, so we annotate > them as global using the new SYM_FUNC_START. And their ENDPROC's by > SYM_FUNC_END. > > And make sure ENTRY/ENDPROC is not defined on X86_64, given these were

[Xen-devel] [linux-linus test] 113945: tolerable FAIL - PUSHED

flight 113945 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/113945/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 12 guest-start fail in 113939 pass in 113945 test-amd64-i386-freebsd10-i386

[Xen-devel] [PATCH v8] x86/hvm: Implement hvmemul_write() using real mappings

From: Andrew Cooper An access which crosses a page boundary is performed atomically by x86 hardware, albeit with a severe performance penalty. An important corner case is when a straddled access hits two pages which differ in whether a translation exists, or in net

Re: [Xen-devel] KVM PV

On 02/10/2017 12:36, George Dunlap wrote: >>> Although I'm not business man, I don't think the top cloud provider[s] >>> would allow nested virtualization, however mature nested virtualization >>> is. Even xen-pv is unable to be nested in the aws and azure. >> >> Check the contributors to KVM

Re: [Xen-devel] [PATCH] libxl: fix generating array of enums in getypes.py

On Fri, Sep 29, 2017 at 04:49:23PM +0300, Oleksandr Grytsov wrote: > From: Oleksandr Grytsov > > Enum always uses "x" value as input argument. In > case of enum array "t" argument should be passed. > > Signed-off-by: Oleksandr Grytsov

Re: [Xen-devel] [RFC] removing proc-xen.mount due to systemd change

On Mon, Oct 02, 2017 at 12:26:24PM +0200, Vasilis Liaskovitis wrote: > Apologies for formatting. Here is my question in plain text: > > There are systemd services that check for dom0 detection before xenfs > gets mounted by proc-xen.mount. See this systemd bug report for an > example: >

Re: [Xen-devel] KVM PV (was: Re: [PATCH v2 2/2] x86/lguest: remove lguest support)

On Sat, Sep 30, 2017 at 4:39 AM, Paolo Bonzini wrote: > > - Lai Jiangshan ha scritto: >> On Sat, Sep 30, 2017 at 12:39 AM, Paolo Bonzini wrote: >> > On 29/09/2017 17:47, Lai Jiangshan wrote: >> >> Hello, all >> >> >> >>

Re: [Xen-devel] [PATCH] libxl: remove dead code in libxl__domain_build_info_setdefault

On Fri, Sep 29, 2017 at 10:53:07AM +0100, Roger Pau Monne wrote: > Spotted by Coverity. > This now has a Coverity ID 1418831. I will add that to commit message. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC] removing proc-xen.mount due to systemd change

Apologies for formatting. Here is my question in plain text: There are systemd services that check for dom0 detection before xenfs gets mounted by proc-xen.mount. See this systemd bug report for an example: https://github.com/systemd/systemd/issues/6442 Upstream systemd has accepted the patch

  1   2   >